X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 18 Jan 2017 11:43:41 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb] why no clearpoly on silk
In-Reply-To: <CAJXU7q-8_Reh8evmpD4uJkmDShbDdOZu=cQ3dsupvjdDonoerA@mail.gmail.com>
Message-ID: <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>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1407765992-1484736221=:7286"
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1407765992-1484736221=:7286
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Wed, 18 Jan 2017, Peter Clifton (petercjclifton AT googlemail DOT com) [via ged=
a-user AT delorie DOT com] wrote:

>I'm not sure it makes much sense to treat it differently, but historically
>it has been. It's not like your clearing a conductive plane object with
>conductive tracks - so I can sort of understand the distinction.
>I'm not sure that the element syntax allows any clearance data in the old
>pcb file format, so only stuff drawn directly on the design layer would be
>affected.
>
>When the clipper code was introduced it changed behaviours, such introduci=
ng
>the "full poly" flag, which when added mostly restored the old geometry
>you'd get from ancient pcb versions without the clipper.=C2=A0 This is all=
 long
>in the past, but at the time created problems where older designs opened
>with different connectivity in newer pcb.

Thanks. So we may have a reason around the auto-drawn silks from elements.=
=20
Good point, I'll take a look at that.

>Given the abundance of existing designs, you might cause silk layer breaka=
ge
>if you suddenly enable clipping there... unless we also special cased
>turning off the flags enabling clearance when drawing / moving new lines o=
n
>the silk layers?

Just to be clear on this, I do not propose any change for mainline for=20
this.

In pcb-rnd we have support for multiple board file formats. Our native=20
format is not pcb but lihata. We support pcb as we support kicad's format.=
=20
The native format supports all features, but the non-native ones don't.

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;=20
I think this would restore the original behaviour on load.

- when silk poly is saved to .pcb, maybe I should put there the clearpoly=
=20
flag, as that's how silk poly exists naturally - but I am not sure about=20
this part yet

- 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=20
wouldn't manipulate the silk poly flags on load or save


Do you think this could work?

Regards,

Igor2

--0-1407765992-1484736221=:7286--