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: References:

From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" Date: Wed, 18 Jan 2017 10:54:59 +0000 Message-ID: Subject: Re: [geda-user] [pcb] why no clearpoly on silk To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a113d7ef68030b605465c3fbe 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 Precedence: bulk --001a113d7ef68030b605465c3fbe Content-Type: text/plain; charset=UTF-8 On 18 Jan 2017 10:38, 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

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 breakag= e
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 pre= serves 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 t= he same improvements.

(B= tw.. 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 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.=

= 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:<= br>
- 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 f= lag, 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) th= at allows to know if the data inside the file is supposed to be correct or = not.

Could do it on vers= ion, assuming you reset the relevant flags on any file loaded before that v= ersion number was set.

<= br>

- 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 w= ouldn'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 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.

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.

Peter

--001a113d7ef68030b605465c3fbe--