| www.delorie.com/archives/browse.cgi | search |
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
| X-Recipient: | geda-user AT delorie DOT com |
| X-Original-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=gmail.com; s=20161025; | |
| h=mime-version:in-reply-to:references:from:date:message-id:subject:to; | |
| bh=pab9qzDl0c8zV28+ANf8+FWv7VXCTDUl61UbHdeEzFg=; | |
| b=ECPOayWM/35wDPe1gL2ZK0UMAet5bUMqkV1YmIXT9DwPpkx3x4vKb/0K4/ug97POi7 | |
| HMTh1/x1g44u8kxtuWpKX1CN+OuAwVYthm+TpWvIfn1qVmn7iZCZRcLScocWRCJQJcvW | |
| txC7dhjsNYAh/s8n2c9Uez+S/B4wr/0HVJwDZLwJYkQ0W3Yi59kIWyg3kduf0gBmDGWy | |
| mKZeuAdb/bFsPEDThqbcWWbaTiE5VFIyUNri8t+vblf9acoyVuHyeZ/gETPxSZQUj/Hz | |
| G4fBDotSEtOgiSgF9cJ7tIBh+394DiwBJ+BOpVJ+m/ncDq3clVYCAl/PERgO4O280siV | |
| HIcw== | |
| X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=1e100.net; s=20161025; | |
| h=x-gm-message-state:mime-version:in-reply-to:references:from:date | |
| :message-id:subject:to; | |
| bh=pab9qzDl0c8zV28+ANf8+FWv7VXCTDUl61UbHdeEzFg=; | |
| b=RFCt8moLundIIXeWWbgZpILTmII8iWlXK6cs2SnNiUXxqzUkh56zxgu17+5CFUdlsY | |
| 7qGEWEmy4P76g1Bj7LQIK5sNBFd+Ojl4dKeYd/1lpQ66B1/lnGd4LSdPPRVsKq5Fxh85 | |
| MRD5i/Y7rXjm6bN58pAFT2u6ppZhPNnC3XQCDwx/fqcx/WYnzLt/oUQjBfq6EDvDy7Fa | |
| e60K2DaHxbSk4N4BZPv+V78JdpUKCqNUZzjtzE9p5x2vjvO3Ty8zNjBprtjbFIj2vDGz | |
| OVAUyb54TTo7QH8JhHvMRyMC0QCtB3Kg+1aGS/ousPIB8xw7KIeOPhf+LwCqP2+oXPFN | |
| coww== | |
| X-Gm-Message-State: | AIkVDXK1NEMwexxVJU7/Gvqgx2T2IhGZWVHE6LbZuOyGzevd2oO4yK5tjsZTiaZ5+Jvi4zFhfmGiCNvWyK2OHg== |
| X-Received: | by 10.31.73.198 with SMTP id w189mr1104572vka.170.1484737726890; |
| Wed, 18 Jan 2017 03:08:46 -0800 (PST) | |
| MIME-Version: | 1.0 |
| In-Reply-To: | <CAJXU7q8O1rdOjsEhcEVn=2xctWNuHHmDfSz+J4rWVPb0NFXULw@mail.gmail.com> |
| References: | <alpine DOT DEB DOT 2 DOT 00 DOT 1701180741180 DOT 7286 AT igor2priv> <alpine DOT DEB DOT 2 DOT 00 DOT 1701180813230 DOT 7286 AT igor2priv> |
| <CAJXU7q-8_Reh8evmpD4uJkmDShbDdOZu=cQ3dsupvjdDonoerA AT mail DOT gmail DOT com> | |
| <alpine DOT DEB DOT 2 DOT 00 DOT 1701181134510 DOT 7286 AT igor2priv> <CAJXU7q8O1rdOjsEhcEVn=2xctWNuHHmDfSz+J4rWVPb0NFXULw AT mail DOT gmail DOT com> | |
| From: | "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> |
| Date: | Wed, 18 Jan 2017 12:08:46 +0100 |
| Message-ID: | <CADL2oCULu3OB9VzKpmGK=sk942JU6QuTcY9FwZPJO4zvHkgUdQ@mail.gmail.com> |
| Subject: | Re: [geda-user] [pcb] why no clearpoly on silk |
| To: | geda-user AT delorie DOT com |
| Reply-To: | geda-user AT delorie DOT com |
| Errors-To: | nobody AT delorie DOT com |
| X-Mailing-List: | geda-user AT delorie DOT com |
| X-Unsubscribes-To: | listserv AT delorie DOT com |
--001a114d5d4ccbc67005465c707d Content-Type: text/plain; charset=UTF-8 Maybe I got something wrong. Normally clearance is between copper while the silk is painted on both? 2017-01-18 11:54 GMT+01:00 Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com>: > > > On 18 Jan 2017 10:38, <gedau AT igor2 DOT repo DOT hu> wrote > > > Given the abundance of existing designs, you might cause silk layer >> breakage >> if you suddenly enable clipping there... unless we also special cased >> turning off the flags enabling clearance when drawing / moving new lines >> on >> the silk layers? >> > > Just to be clear on this, I do not propose any change for mainline for > this. > > > No, but it's one worth considering if it can be done in a way that > preserves behaviour of existing files. > > I'd like to try to keep compatibility with pcb-rnd where we can, and there > seems no real point in reinventing different ways to make the same > improvements. > > (Btw.. Would dearly love to kill off debug draw in mainline too, as it's a > nuisance) > > In pcb-rnd we have support for multiple board file formats. Our native > format is not pcb but lihata. We support pcb as we support kicad's format. > The native format supports all features, but the non-native ones don't. > > > Point me at the libhata docs at some point if you get a chance? > > > So my removal of this restriction in pcb-rnd would do something like this: > > - if silk polys are loaded from .pcb, I'd remove the clearpoly flag; I > think this would restore the original behaviour on load. > > > I think so. > > - when silk poly is saved to .pcb, maybe I should put there the clearpoly > flag, as that's how silk poly exists naturally - but I am not sure about > this part yet > > > I guess one way might to have a test for version (or flag) that allows to > know if the data inside the file is supposed to be correct or not. > > Could do it on version, assuming you reset the relevant flags on any file > loaded before that version number was set. > > > - same rules apply to curret (then-old) version of the lihata format > > - I'd bump the version of the lihata board format and the new version > wouldn't manipulate the silk poly flags on load or save > > > Do you think this could work? > > > Sounds workable to me. > > I'm still trying to recall if the clipper always worked this way, or > whether it was a dumb change I introduced in an attempt to speed up cutting > to a buffer or something. > > I don't "think" the silk lines ever used to clear, but I could be wrong. > I'd bet historically, the behaviour goes back to before the clipper - when > clearances in planes were drawn in negative on polygons directly from > bloated track geometry. > > > Peter > --001a114d5d4ccbc67005465c707d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Maybe I got something wrong. Normally clearance is between= copper while the silk is painted on both?</div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">2017-01-18 11:54 GMT+01:00 Peter Clifton (<a= href=3D"mailto:petercjclifton AT googlemail DOT com">petercjclifton AT googlemail DOT co= m</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com<= /a>] <span dir=3D"ltr"><<a href=3D"mailto:geda-user AT delorie DOT com" target= =3D"_blank">geda-user AT delorie DOT com</a>></span>:<br><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"><div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br>= <div class=3D"gmail_quote">On 18 Jan 2017 10:38, <<a href=3D"mailto:ged= au AT igor2 DOT repo DOT hu" target=3D"_blank">gedau AT igor2 DOT repo DOT hu</a>> wrote<span = class=3D""><blockquote class=3D"m_4699465376180990399quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"m_46= 99465376180990399quoted-text"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Given the abundance of existing designs, you might cause silk layer breakag= e<br> if you suddenly enable clipping there... unless we also special cased<br> turning off the flags enabling clearance when drawing / moving new lines on= <br> the silk layers?<br> </blockquote> <br></div> Just to be clear on this, I do not propose any change for mainline for this= .<br></blockquote></span></div></div><div dir=3D"auto"><br></div><div dir= =3D"auto">No, but it's one worth considering if it can be done in a way= that preserves behaviour of existing files.</div><div dir=3D"auto"><br></d= iv><div dir=3D"auto">I'd like to try to keep compatibility with pcb-rnd= where we can, and there seems no real point in reinventing different ways = to make the same improvements.</div><div dir=3D"auto"><br></div><div dir=3D= "auto">(Btw.. Would dearly love to kill off debug draw in mainline too, as = it's a nuisance)</div><span class=3D""><div dir=3D"auto"><br></div><div= class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote = class=3D"m_4699465376180990399quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> In pcb-rnd we have support for multiple board file formats. Our native form= at is not pcb but lihata. We support pcb as we support kicad's format. = The native format supports all features, but the non-native ones don't.= <br></blockquote></div></div><div dir=3D"auto"><br></div></span><div dir=3D= "auto">Point me at the libhata docs at some point if you get a chance?</div= ><span class=3D""><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><= div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquo= te class=3D"m_4699465376180990399quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> So my removal of this restriction in pcb-rnd would do something like this:<= br> <br> - if silk polys are loaded from .pcb, I'd remove the clearpoly flag; I = think this would restore the original behaviour on load.<br></blockquote></= div></div><div dir=3D"auto"><br></div></span><div dir=3D"auto">I think so.<= /div><span class=3D""><div dir=3D"auto"><br></div><div class=3D"gmail_extra= " dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"m_4699465376= 180990399quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddi= ng-left:1ex"> - when silk poly is saved to .pcb, maybe I should put there the clearpoly f= lag, as that's how silk poly exists naturally - but I am not sure about= this part yet<br></blockquote></div></div><div dir=3D"auto"><br></div></sp= an><div dir=3D"auto">I guess one way might to have a test for version (or f= lag) that allows to know if the data inside the file is supposed to be corr= ect or not.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Could do it = on version, assuming you reset the relevant flags on any file loaded before= that version number was set.</div><span class=3D""><div dir=3D"auto"><br><= /div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto"><d= iv class=3D"gmail_quote"><blockquote class=3D"m_4699465376180990399quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - same rules apply to curret (then-old) version of the lihata format<br> <br> - I'd bump the version of the lihata board format and the new version w= ouldn't manipulate the silk poly flags on load or save<br> <br> <br> Do you think this could work?<br></blockquote></div></div><div dir=3D"auto"= ><br></div></span><div dir=3D"auto">Sounds workable to me.</div><div dir=3D= "auto"><br></div><div dir=3D"auto">I'm still trying to recall if the cl= ipper always worked this way, or whether it was a dumb change I introduced = in an attempt to speed up cutting to a buffer or something.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">I don't "think" the sil= k lines ever used to clear, but I could be wrong. I'd bet historically,= the behaviour goes back to before the clipper - when clearances in planes = were drawn in negative on polygons directly from bloated track geometry.</d= iv><span class=3D"HOEnZb"><font color=3D"#888888"><div dir=3D"auto"><br></d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">Peter</div></font></span><= /div> </blockquote></div><br></div> --001a114d5d4ccbc67005465c707d--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |