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

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

- Raw text -