kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2014-09-10 19:41 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>:
> On 9/10/2014 1:12 PM, Lorenzo Marcantonio wrote:
>> On Wed, Sep 10, 2014 at 05:49:27PM +0100, Brian Sidebotham wrote:
>>> Fair enough, I disagree and this just over-complicates things
>>> needlessly in my opinion. You'll have to track all of the layers that
>>> we're going to allow text to appear on in a module and limit the layer
>>> selector to that range and duplicate that in all the functions that
>>> have to deal with this - it's just more assumptions that end in
>>> disaster or limited functionality in the end.
>>>
>>> My opinion - just allow module text on any layer. Give the module
>>> designer flexibility. That way we don't need more special cases, and
>>> functions do what they say on the tin without needing
>>> IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever()
>>
>> After all this... actually we *are* going to allow text in modules on
>> every layer (except for copper probably), so it's going to be as you are
>> saying now.
>>
>> The discussion was *only* for the picker/collector which is initialized
>> by the user view controls (layers and visibles).
>>
>> Practical example: I have a module with text on B_Fab. This module is on
>> the back, so the module's layer is B_Cu. Since it's been flipped the
>> text actually appears on F_Fab.
>>
>> However:
>> - If the user has disabled bottom modules it shouldn't appear/be picked,
>>   since it's from a flipped module;
>> - If the user has disabled front text it shouldn't appear/be picked,
>>   since F_Fab (the resulting layer) is on the front;
>> - If the user has disabled F_Fab it shouldn't appear/be picked since the
>>   text layer is disabled.
>>
>> That's only for *user* text. Rules for reference/value are (in the same
>> use case)
>> - If the user has disabled bottom modules it shouldn't appear/be picked,
>>   since it's from a flipped module; (same as before)
>> - If the user has disabled *back* text it shouldn't appear/be picked,
>>   since B_Silk (the resulting layer flipping the implicit F_Silk) is on
>>   the back;
>> - Even if you disable B_Silk it's still shown... because it always
>>   worked that way :D
>>
>> Reference and value are special enough to have different rules. You can
>> only hide them disabling the corresponding module side or the
>> corresponding module text.
>>
>
> Perhaps we should define the layer behavior for footprint text and
> non-footprint text first and then make the code match the behavior.  It
> seems to me once you have the behavior defined, the code should be
> fairly straight forward.  I guess the real question is do we want to
> keep the current text layer behavior or do we want to design something
> that is more flexible?

In that regard, I wil try my luck throwing in a comment/question. I
will have a hard time contribution any further to the exact dicussion
though.

Why is it that it is undesireable to have text on the copper layer? I
have sometimes wanted to embed text in the copper, and have the flood
fill into wher the text is, and the actual text be no copper. Is this
a limitation with ERC, for example how to handle islands? I once tried
to do that in Altium, but failed to get the fill to work the way I
wanted, instead I got an ugly textbox wiht the text inside. This is
also what I see in Kicad currently. So what I want is kind of an
inverted text, which is able to connect to a filled zone.

I have worked around this issue in kicad once with the
bitmap2component tool, but this is not nice.

Nick