2014-09-10 19:41 GMT+02:00 Wayne Stambaugh <[email protected]>: > 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
