2017-01-18 11:54 GMT+01:00 Peter Clifton (petercjclifton AT googlemail DOT co= m) [via geda-user AT delorie DOT com<= /a>] <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 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 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 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?

<= div class=3D"gmail_extra" dir=3D"auto">
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.<= /div>

- 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 f= lag) that allows to know if the data inside the file is supposed to be corr= ect or not.

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

<= /div>

- 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 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.

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.

Peter

<= /div>

--001a114d5d4ccbc67005465c707d--