X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 1 Dec 2015 20:42:53 +0100
From: Martin Beranek <martin AT mb5 DOT cz>
To: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] PCB: clearouts in polygons slightly off, fix?
Message-ID: <20151201194252.GA2293@abax>
References: <20151201124843 DOT GC24702 AT abax>
 <201512011841 DOT tB1IfDIJ018459 AT envy DOT delorie DOT com>
 <20151201201559 DOT df10bda12d53ff7d8b55461e AT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151201201559.df10bda12d53ff7d8b55461e@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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

> Yes for cases where the output is demonstrably "wrong" there is a
> problem hidden somewhere.
> 
> Approximation is more about needed accuracy, in real life accuracy is
> never perfect. If approximation start to add up for example each time
> an object is moved it is however a problem, I guess a grid more course
> than total approximation error could solve this.

The approximation itself has nothing to do with the grid. It is only
that polygon code does not work with arcs, so these have to be replaced
by reasonable number of straight segments. So far OK (yes, there is a
note in the code comments about possibility to use real arcs, but such
change would likely affect quite a lot of other things too). But the
code approximating arc by polyline does it in wrong way. Most notably
endpoints of the replacement are wrong, so preceding and following
straight segments gets skewed completely unnecessary.

Yes, the difference is in most cases minimal, but it is real and it is
there. It is no rounding error or something like this.

Martin