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
	:content-type;
	bh=NgTo5zjsJoB4FBbYd8xPK32ctH3BTSfS9i5/vCL928E=;
	b=vQUvvuSQSpHE/Kjt0UX7hJR9pOLWDvjHzztc+e43jaaERnDANj3qXrr2B5wnhToY4q
	z4YiAHrTwLnHDIfXQPvS5vz+NxHbtsSs0fl3U3fbzFEfAE6zpMLxwjsqNEaC20tDwADE
	fePLmFLmclV38W7TapU5aIng42K15DmzZdlIuO8LiDtbH3aQ6iqwsbHte9Oiq01PEJLR
	85g2+NHEMdIqCXdBcmogXJPHrFtPx6Vx74mqWiDY3nGsBXRt5As9P+J50f1lOU3ekaks
	5BHOvkgSU54igDEFnFMXESEs3VY7mCiWBDLd5uZXcBAzE4L9Gq+uJR82OWdBofIVOqdt
	4ZMg==
MIME-Version:	1.0
X-Received:	by 10.60.59.101 with SMTP id y5mr63464499oeq.61.1452513223661;
	Mon, 11 Jan 2016 03:53:43 -0800 (PST)
In-Reply-To:	<7B419D4C-A638-4DA8-AD74-EC3C56CFC9A7@icloud.com>
References:	<CAJXU7q8edycnyhZbZ7+M3q6HA13U4Tr5R9M7KAG59HVpH2+cMg AT mail DOT gmail DOT com>
	<56928D6F DOT 6080807 AT ecosensory DOT com>
	<CE3B7FFB-7C6F-48CB-ADA9-A42D85A3C022 AT noqsi DOT com>
	<5692AFEC DOT 9060807 AT ecosensory DOT com>
	<20160110213849 DOT 460c7bb14e8f6645138bebd8 AT gmail DOT com>
	<s6nsi25doll DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160111080228 DOT GA32662 AT visitor2 DOT iram DOT es>
	<20160111094144 DOT bee82694c414c1cc36b98cf8 AT gmail DOT com>
	<5693884C DOT 7080003 AT iee DOT org>
	<CAJXU7q8jzqqDkXbVXpadApYPg+YPKVPcQkR1Uq-ynJz_+XZMPg AT mail DOT gmail DOT com>
	<7B419D4C-A638-4DA8-AD74-EC3C56CFC9A7 AT icloud DOT com>
Date:	Mon, 11 Jan 2016 11:53:43 +0000
Message-ID:	<CAJXU7q_oS9pym87fHjNgJeKH+XOMBOJP9hXjC7Lg88ZiXN483g@mail.gmail.com>
Subject:	Re: [geda-user] Primitive electrical types --> layers
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

--089e0149d164ba86b505290d96c1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 Jan 2016 11:44, "Chris Smith (space DOT dandy AT icloud DOT com) [via
geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:

> Out of curiosity, why bother with any other types of drawing primitive
than polygons made up of bezier curves?  Surely at the scale we=E2=80=99re =
talking
about (nanometers) even traces are just polygons with predominantly
parallel edges.  Wouldn=E2=80=99t it simplify the library functions if we j=
ust had
to handle interactions between polygons, and make things like trace endings
(rounded, square, teardrop) easier?

In theory that is a nice idea, and one which often comes to mind when we
consider DRC and other operations which act upon the geometery.

In reality, the polygon processing isn't as robust as we'd need, can be
quite slow and underlying it, people will expect to draw tracks from either
line segments or poly curves (depending on the package).

At the design stage, CSG 2D geometery (adding / subtracting primitive
shapes) is still the norm.

Perhaps at some point we will move to a more generic geometery model for
aspects of the processing. Things like gcode export etc... Would be better
served by exact outline models of the boolean sum of our CSG primitives.

Peter

>
> Chris
> =E2=80=94
> Chris Smith <space DOT dandy AT icloud DOT com>
>
>
>

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

<p dir=3D"ltr"><br>
On 11 Jan 2016 11:44, &quot;Chris Smith (<a href=3D"mailto:space DOT dandy AT iclo=
ud.com">space DOT dandy AT icloud DOT com</a>) [via <a href=3D"mailto:geda-user AT delori=
e.com">geda-user AT delorie DOT com</a>]&quot; &lt;<a href=3D"mailto:geda-user AT del=
orie.com">geda-user AT delorie DOT com</a>&gt; wrote:</p>
<p dir=3D"ltr">&gt; Out of curiosity, why bother with any other types of dr=
awing primitive than polygons made up of bezier curves?=C2=A0 Surely at the=
 scale we=E2=80=99re talking about (nanometers) even traces are just polygo=
ns with predominantly parallel edges.=C2=A0 Wouldn=E2=80=99t it simplify th=
e library functions if we just had to handle interactions between polygons,=
 and make things like trace endings (rounded, square, teardrop) easier?</p>
<p dir=3D"ltr">In theory that is a nice idea, and one which often comes to =
mind when we consider DRC and other operations which act upon the geometery=
.</p>
<p dir=3D"ltr">In reality, the polygon processing isn&#39;t as robust as we=
&#39;d need, can be quite slow and underlying it, people will expect to dra=
w tracks from either line segments or poly curves (depending on the package=
).</p>
<p dir=3D"ltr">At the design stage, CSG 2D geometery (adding / subtracting =
primitive shapes) is still the norm.</p>
<p dir=3D"ltr">Perhaps at some point we will move to a more generic geomete=
ry model for aspects of the processing. Things like gcode export etc... Wou=
ld be better served by exact outline models of the boolean sum of our CSG p=
rimitives.</p>
<p dir=3D"ltr">Peter</p>
<p dir=3D"ltr">&gt;<br>
&gt; Chris<br>
&gt; =E2=80=94<br>
&gt; Chris Smith &lt;<a href=3D"mailto:space DOT dandy AT icloud DOT com">space.dandy@=
icloud.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</p>

--089e0149d164ba86b505290d96c1--

- Raw text -