| 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=googlemail.com; s=20161025; | |
| h=mime-version:in-reply-to:references:from:date:message-id:subject:to; | |
| bh=8kv8y2Zu/1Dco1YIOQxzAl1XiZQhj+QIgQcCtbmvDY4=; | |
| b=Ob+ES7owdbudCC+WBoE9GgvcCKraR4Sp+ubeEoL9KxNE84tEhCx6zdBJluM220xvep | |
| uQunSb1NvFpJrDRSIluJn4NdV/usxVD62dKHZAg7/cfQkcYs9hwoBXl7uX2meOdTnEGH | |
| 4sFKcv1d0hfPjlpiz4gUlyGFK/L2sIoScG4wAV/C1UGVBu8PL+Q8NivTYfFhwLkaAMu7 | |
| GSjqSRcr2VfwgnPViT93NPYAJPQEHiAJM9xRYSGzpuNIHu2T4MdhGSSRjKPAK0oQiRMH | |
| G7R+nsU0DTa3jgXVlLCXXJTPo9I/94kGiWdF6VoppRTbo7kRI0Tg3REskuEViKSYOxpO | |
| +zRA== | |
| 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=8kv8y2Zu/1Dco1YIOQxzAl1XiZQhj+QIgQcCtbmvDY4=; | |
| b=hcQ0v2LvA+HHr+G3d5TqqkqzpuKOmbrim+v1CeX/pUmMky18gNwMfuC8wdFY3TcQEv | |
| QtHZbHGptRsecpKhPxUhOwF9MKZHyd1okzw4wX9HxJsmmylYHCwCzW0MmqGqKL9PRuiL | |
| dsXiGDkt7RvAe99UQ6yUdx7sBnq67jiYlUbeCWGoYV1eulMsMp9zXwyxiFhkRPUTDYsj | |
| DeETY/uuYKNPovhM7pvMbG+AW2dTETnaPW/LBYvjyj4IfKucj85wnDg3qDiEOEomneAa | |
| 1kb0/M8TcHNToqzPgIoZEHfikl5wwNUPh+R9/JtlJhrKFCMVQel3GVvzMdijqz8v/vkj | |
| J7aQ== | |
| X-Gm-Message-State: | AIkVDXLmK/jbSI0iOMxNBZB7RI4aF79ocxWF4Q5AvR8V+metcohhoUqjLJxSepDcTkBVvr+CEF95WF3eQUsbaQ== |
| X-Received: | by 10.237.37.165 with SMTP id x34mr2090872qtc.218.1484736899851; |
| Wed, 18 Jan 2017 02:54:59 -0800 (PST) | |
| MIME-Version: | 1.0 |
| In-Reply-To: | <alpine.DEB.2.00.1701181134510.7286@igor2priv> |
| 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> | |
| From: | "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> |
| Date: | Wed, 18 Jan 2017 10:54:59 +0000 |
| Message-ID: | <CAJXU7q8O1rdOjsEhcEVn=2xctWNuHHmDfSz+J4rWVPb0NFXULw@mail.gmail.com> |
| Subject: | Re: [geda-user] [pcb] why no clearpoly on silk |
| To: | gEDA User Mailing List <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 |
--001a113d7ef68030b605465c3fbe Content-Type: text/plain; charset=UTF-8 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 --001a113d7ef68030b605465c3fbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><br><div class=3D"gmail_extra" dir=3D"auto"><br><div clas= s=3D"gmail_quote">On 18 Jan 2017 10:38, <<a href=3D"mailto:gedau AT igor2.= repo.hu">gedau AT igor2 DOT repo DOT hu</a>> wrote<blockquote class=3D"quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div cla= ss=3D"quoted-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></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 pre= serves behaviour of existing files.</div><div dir=3D"auto"><br></div><div d= ir=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 t= he same improvements.</div><div dir=3D"auto"><br></div><div dir=3D"auto">(B= tw.. Would dearly love to kill off debug draw in mainline too, as it's = a nuisance)</div><div dir=3D"auto"><br></div><div class=3D"gmail_extra" dir= =3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"m= argin: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><div dir=3D"auto">= Point me at the libhata docs at some point if you get a chance?</div><div d= ir=3D"auto"><br></div><div dir=3D"auto"><br></div><div class=3D"gmail_extra= " dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"quote" style= =3D"margin:0 0 0 .8ex;border-left: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><div dir=3D"auto">I think so.</div><d= iv dir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto"><div clas= s=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-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><div= dir=3D"auto">I guess one way might to have a test for version (or flag) th= at allows to know if the data inside the file is supposed to be correct or = not.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Could do it on vers= ion, assuming you reset the relevant flags on any file loaded before that v= ersion number was set.</div><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"= ><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc= c 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><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 clipper a= lways worked this way, or whether it was a dumb change I introduced in an a= ttempt 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 silk lines e= ver used to clear, but I could be wrong. I'd bet historically, the beha= viour goes back to before the clipper - when clearances in planes were draw= n in negative on polygons directly from bloated track geometry.</div><div d= ir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Peter</= div></div> --001a113d7ef68030b605465c3fbe--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |