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=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=m/aUzSn8EC87GzRvBdog7lZJosPBWP339+Z+M9RALTk=;
        b=VejjKPOVMLDG9jic18cZ8hOiuGVZK0FhWhwqI059x/MMYSHFx75ndgjE6BsIpzB1yZ
         KOnb0AzjTBwI55JyP9ruPecpChRh4HOGx/9D0oSUDQfcr1/NhxSiORZGlebuzYtQ9StS
         3+KAu51RyyF2+pqhVoj0U7WwZkRuT0O8U2UOZLnzYg4He4keWkOiXZOwxNL+aENh61Y1
         wHryvemDpP3FH6IZXRd57cvIny1LTE6vDa9Z1iqCpci2hEWcYji27rVlTfApRLmLJJq+
         h+9HoplhTaM7w86jQ/oW9CI26cnrGC74oRs74O9ISiL9VcY9sbztqhWtQc7+J+Y+tuIe
         fnXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to;
        bh=m/aUzSn8EC87GzRvBdog7lZJosPBWP339+Z+M9RALTk=;
        b=iIOX6zqiAlN1HRJoZdytx8efRYLXpyJrlcYF5oGkpRZtKEyVXK5VS6MuHKQW32ezej
         D9xhLAJxTGewMERw7xowvrUpAOjm0SAXafZAQOSdSxKcgZlqfFKVTsKnSZ8gSbHbfDwz
         mZCJ/h6rUMkqLFPA2EO3gi236+GG4uNQzPOe59m9TOVzRYupYRwRBHL9goPHAnWJdFAA
         5NMwqnrjpGTPhukxF0qAxOUNX5A6CKmbfRBQQKT0jnvusIeBdDRzwkM5FCn5Ku++LQRf
         +eS+kU2mI7gpLoTIMpaxukg9lNNmQJBGd4yRL3Z2JThzKn7ShY7+7XiHJ4WRbYIEW6TO
         sY6g==
X-Gm-Message-State: AEkoouuugQuAX8BuhMA4IWDvs4rZZAq9FzKxycMWw7D4fBlFj7K9zapK8XH7ZJy+Pfj/RobK7aSWFppmw9DmWw==
MIME-Version: 1.0
X-Received: by 10.36.210.10 with SMTP id z10mr12760438itf.3.1470042094594;
 Mon, 01 Aug 2016 02:01:34 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.00.1608010641230.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1608010641230 DOT 7286 AT igor2priv>
Date: Mon, 1 Aug 2016 10:01:34 +0100
Message-ID: <CAJXU7q_vs=_jkvET8zJ-siU8PqnzcyDOh9bfkxFH1R2ec0baJQ@mail.gmail.com>
Subject: Re: [geda-user] pcb bugreport: poly
From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Content-Type: multipart/alternative; boundary=94eb2c0574deda71480538fed82b
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

--94eb2c0574deda71480538fed82b
Content-Type: text/plain; charset=UTF-8

Do anything other than 3. :)

I think 2. is likely the best option, since it doesn't require any
automatic changes to design data.

On 1 Aug 2016 5:55 a.m., <gedau AT igor2 DOT repo DOT hu> wrote:

> Hi all,
>
> miloh reported this bug while testing pcb-rnd using pstoedit imported
> data. A minimal example is attached.
>
> If you compile the code with debug enabled (see also: -DNDEBUG), a check
> catches this. When drawing such a poly, the code asserts when closing it.
> When loading a file with a poly like that, the code asserts while loading.
>
> With debug disabled (a.k.a. normal production code, asserts and checks
> disabled), it both loads and displays, and it can also be drawn. Using the
> poly may lead to strange effects, tho. The easiest-to-trigger thing is
> panning in softwar render mode (lesstif or --disable-gl with gtk): when
> panning so that some points of the poly is off the screen, it results in
> strange artifacts.
>
> Simply catching such polygons during draw is not enough, because external
> tools & scripts and old designs can have them any time.
>
> I am not sure how this should be solved, but I believe consistent
> behaviour among debug and no-debug compilation would be better. Proposed
> solutions:
>
> 1. After draw or during load, split up the invalid poly to a set of valid
> polys. There's code for drawing that does similar things already. Pro:
> "works as expected" in all cases. Con: a simple load-save cycle may change
> the file (fixing the polys)
>
> 2. on load, stop and report error in non-debug mode; while drawing, remove
> the polygon if it is invalid. Maybe provide an external tool that can fix
> up old/external files by splitting up invalid polygons.
>
> 3. relax the requirement of non-intersecting polygons everywhere, making
> it a normal case. This would be a large amount of work, potentially
> affecting all current exporters. It'd also affect future exporters,
> probably requiring more efforts to write one as "canonical polygons" can
> not be expected.
>
> Regards,
>
> Igor2
>
>

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

<p dir=3D"ltr">Do anything other than 3. :)</p>
<p dir=3D"ltr">I think 2. is likely the best option, since it doesn&#39;t r=
equire any automatic changes to design data.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 1 Aug 2016 5:5=
5 a.m.,  &lt;<a href=3D"mailto:gedau AT igor2 DOT repo DOT 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:1px #ccc solid;padding-left:1ex">Hi all,<=
br>
<br>
miloh reported this bug while testing pcb-rnd using pstoedit imported data.=
 A minimal example is attached.<br>
<br>
If you compile the code with debug enabled (see also: -DNDEBUG), a check ca=
tches this. When drawing such a poly, the code asserts when closing it. Whe=
n loading a file with a poly like that, the code asserts while loading.<br>
<br>
With debug disabled (a.k.a. normal production code, asserts and checks disa=
bled), it both loads and displays, and it can also be drawn. Using the poly=
 may lead to strange effects, tho. The easiest-to-trigger thing is panning =
in softwar render mode (lesstif or --disable-gl with gtk): when panning so =
that some points of the poly is off the screen, it results in strange artif=
acts.<br>
<br>
Simply catching such polygons during draw is not enough, because external t=
ools &amp; scripts and old designs can have them any time.<br>
<br>
I am not sure how this should be solved, but I believe consistent behaviour=
 among debug and no-debug compilation would be better. Proposed solutions:<=
br>
<br>
1. After draw or during load, split up the invalid poly to a set of valid p=
olys. There&#39;s code for drawing that does similar things already. Pro: &=
quot;works as expected&quot; in all cases. Con: a simple load-save cycle ma=
y change the file (fixing the polys)<br>
<br>
2. on load, stop and report error in non-debug mode; while drawing, remove =
the polygon if it is invalid. Maybe provide an external tool that can fix u=
p old/external files by splitting up invalid polygons.<br>
<br>
3. relax the requirement of non-intersecting polygons everywhere, making it=
 a normal case. This would be a large amount of work, potentially affecting=
 all current exporters. It&#39;d also affect future exporters, probably req=
uiring more efforts to write one as &quot;canonical polygons&quot; can not =
be expected.<br>
<br>
Regards,<br>
<br>
Igor2<br>
<br>
</blockquote></div></div>

--94eb2c0574deda71480538fed82b--