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=uhdyEsVzpLI87PDJTMw+zT0q5dTzSaL0chLOW5Wbopc=;
        b=u1lhaQphw2M48Wr9Tjlk3gWMCjiqYTaDXigLjEAKaTgbEYq8iEA5abuzh/K0cTdX1n
         Pm0v9dQnj5VnIHEW5LEMBjacGGIr3lAE194qld/Em3fPfAM5aiBriwKdK8kF7+qra0MB
         c6wi6J3fWNSQcS7QMztcSIeR3+Wr8rHOwqLyfycG2f+HZ/JfTYokE9sSEJfS38Mse2yw
         DgnaW3bCM9UxgcmyFaMZdbh29vDRHzDIrzTY+8k0O10jWHnYnZRb8Sz7h0mmS4/vnsUE
         jTxEdUTki2qTFtjYTrjZBnQA/pSNxy4d/4MFLzsV+JMx22+BTHvcbSTI9bYS7XAX9dov
         v9sg==
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=uhdyEsVzpLI87PDJTMw+zT0q5dTzSaL0chLOW5Wbopc=;
        b=mtn81eMqsS6HrhCm+8C+bjeLrG3lPDrpMQoZKRNbqs2VNHa7aIxKJVKgLy1CVgPsag
         KVMR3U9zkEPaIhksOjFGY4pfvwu3I6dBK94xIe4JSI4CBpCskR06WOWVZr78s0bV5SCH
         GsuRoeJhLyEm5UYiVvMJlmefvbA4AcRgRPXR410Yj5FaAo61XRbYcBOjRMi/GDv3GwpA
         y/sdYMNlTiPqrGBdhICAL08IW/n4+3+J+WhUesZK7fCWzxuloZZAxPk96OHJ/fXGQ9p7
         QcHB0K1N54fq4COzNEMSKCrXAUZhOuuwcKg3Nhz2Z0ITCXnhbt8gV5NBDeSnT15okYeL
         nNtQ==
X-Gm-Message-State: AIkVDXJ35Sg5KPG/n7JDKtrOxddX6g3LTBrPignzn0AgdOMZA6ToaPbxLKFupa7Z/hminHKB4CUncQtURhiWAg==
X-Received: by 10.200.56.76 with SMTP id r12mr1978548qtb.2.1484734296076; Wed,
 18 Jan 2017 02:11:36 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1701180813230.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>
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:11:35 +0000
Message-ID: <CAJXU7q-8_Reh8evmpD4uJkmDShbDdOZu=cQ3dsupvjdDonoerA@mail.gmail.com>
Subject: Re: [geda-user] [pcb] why no clearpoly on silk
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Content-Type: multipart/alternative; boundary=001a1137d9ec4dbdcb05465ba447
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

--001a1137d9ec4dbdcb05465ba447
Content-Type: text/plain; charset=UTF-8

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
introducing the "full poly" flag, which when added mostly restored the old
geometry you'd get from ancient pcb versions without the clipper.  This is
all long in the past, but at the time created problems where older designs
opened with different connectivity in newer pcb.

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?

Peter

On 18 Jan 2017 07:11, <gedau AT igor2 DOT repo DOT hu> wrote:

> Hi all,
>
> sligtly related to the disappearing silk poly: we do not let polygon
> clearance happen on silk. It's disabled even if both clearline and
> clearpoly are set. Does anyone remember what was the reason for this? Is it
> only that it "doesn't seem practical"? If so, why don't we just let the
> user control this with those flags we already have?
>
> (The relation is that the bug can not be reproduced if the clearpoly flag
> is not set on the silk poly.)
>
> I'm asking this because I am planning to remove this limitation in pcb-rnd
> and let users do clearpoly in whatever layer they want to.
>
> Regards,
>
> Igor2
>

--001a1137d9ec4dbdcb05465ba447
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I&#39;m not sure it makes much sense to treat it differen=
tly, but historically it has been. It&#39;s not like your clearing a conduc=
tive plane object with conductive tracks - so I can sort of understand the =
distinction.<div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m not sure =
that the element syntax allows any clearance data in the old pcb file forma=
t, so only stuff drawn directly on the design layer would be affected.<br><=
div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">When the cli=
pper code was introduced it changed behaviours, such introducing the &quot;=
full poly&quot; flag, which when added mostly restored the old geometry you=
&#39;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 ope=
ned with different connectivity in newer pcb.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Given the abundance of existing designs, you might ca=
use 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?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Peter</div></div></div></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On 18 Jan 2017 07:11,  &lt;<a href=3D"mailto:gedau=
@igor2.repo.hu">gedau AT igor2 DOT repo DOT hu</a>&gt; wrote:<br type=3D"attribution">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi all,<br>
<br>
sligtly related to the disappearing silk poly: we do not let polygon cleara=
nce happen on silk. It&#39;s disabled even if both clearline and clearpoly =
are set. Does anyone remember what was the reason for this? Is it only that=
 it &quot;doesn&#39;t seem practical&quot;? If so, why don&#39;t we just le=
t the user control this with those flags we already have?<br>
<br>
(The relation is that the bug can not be reproduced if the clearpoly flag i=
s not set on the silk poly.)<br>
<br>
I&#39;m asking this because I am planning to remove this limitation in pcb-=
rnd and let users do clearpoly in whatever layer they want to.<br>
<br>
Regards,<br>
<br>
Igor2<br>
</blockquote></div></div>

--001a1137d9ec4dbdcb05465ba447--