X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Envelope-From:	paubert AT iram DOT es
Date:	Wed, 15 Jan 2014 15:47:14 +0100
From:	Gabriel Paubert <paubert AT iram DOT es>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] More about the polygon bug
Message-ID:	<20140115144714.GA26929@visitor2.iram.es>
References:	<1389724747 DOT 2125 DOT 14 DOT camel AT AMD64X2 DOT fritz DOT box>
	<20140115075126 DOT GB23770 AT visitor2 DOT iram DOT es>
	<1389793999 DOT 2083 DOT 8 DOT camel AT AMD64X2 DOT fritz DOT box>
MIME-Version:	1.0
In-Reply-To:	<1389793999.2083.8.camel@AMD64X2.fritz.box>
User-Agent:	Mutt/1.5.20 (2009-06-14)
X-Spamina-Bogosity:	Unsure
X-Spamina-Spam-Score:	-0.2 (/)
X-Spamina-Spam-Report:	Content analysis details: (-0.2 points)
	pts rule name description
	---- ---------------------- --------------------------------------------------
	-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
	[score: 0.5056]
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

On Wed, Jan 15, 2014 at 02:53:19PM +0100, Stefan Salewski wrote:
> On Wed, 2014-01-15 at 08:51 +0100, Gabriel Paubert wrote:
> > > 
> > > Gabriel, please test your gerbers after undo/redo.
> > 
> > They are fine.
> 
> Of course, undo/redo operation before each gerber generation can not be
> a valid solution :-)
> 
> For me it seems that a MoveObject(+1,+0,nm) followed by a MoveObject(-1,
> +0,nm) also suppressed that bug. And I think that these operations
> really should not change the internal ordering of what ever (undo/redo
> may do). It is really an interesting bug. Unfortunately I have currently
> not the time to really investigate the source code...
> 
> I have seen the patch of Robert Drehmel, but he has not given a fine
> explanation WHY it works, so I can not consider that patch really a
> solution.
> 
> > 
> > Note that it seems that one characteristic of the bug is that the
> > line width + twice the clearance (i.e., the "antiline width") 
> > is exactly the width of the pad. But the coordinate system in PCB
> > uses integers (a good idea to avoid floating point pitfalls).
> > I've tested both 32 bit (not x86, ppc) and 64 bit systems and
> > the bug shows in both.
> 
> Also an interesting observation!

More or less confirmed, it disappears when changing the width (either way)
by 100nm (the resolution at which the data is saved in the .pcb files).

	Regards,
	Gabriel

- Raw text -