#184 Copper pour drawing bugs.

[Timmmm]

Hi, you can see in the attachment that there are some drawing bugs in all render modes for the gerber I have. The top one is rendered with another viewer that gets it right. Gerbv in fast mode gets it pretty wrong - looks like the copper pour area is stroked with a non-zero thickness, and there are gaps too! High quality mode is better but then it totally misses out half of the hole.

The gerbers were generated with DesignSparkPCB. Unfortunately I can't share them, but the hole is just a large circular pad with a plated hole in it, and then a copper pour around it. Designspark seems to do copper pours in horizontal segments so it might make a difference if there are lots of tracks and pads at the same horizontal level as the hole.

Anyway, something is screwed up here!

[hirschma]

I'm seeing similar errors from DipTrace output (and have for years, actually), but it seems to happen depending upon magnification. See attachments.

I'm pretty sure that DipTrace is doing pours "incorrectly", but it does work for actual PCBs.

This is on Windows and Linux, 2.6.1 back to 2.4.x if I recall correctly.

[Stuart Brorson]

Hi, you can see in the attachment that there are some drawing bugs in all render modes for the gerber I have. The top one is rendered with another viewer that gets it right. Gerbv in fast mode gets it pretty wrong - looks like the copper pour area is stroked with a non-zero thickness, and there are gaps too! High quality mode is better but then it totally misses out half of the hole.

The gerbers were generated with DesignSparkPCB. Unfortunately I can't share them, but the hole is just a large circular pad with a plated hole in it, and then a copper pour around it. Designspark seems to do copper pours in horizontal segments so it might make a difference if there are lots of tracks and pads at the same horizontal level as the hole.

Try looking at your Gerbers using GCPrevue:

http://www.graphicode.com/GC-Prevue

See if you have the same problem.

Stuart

[Timmmm]

According to the guys at OSHPark who use a gerbv-based renderer, it is due to polygons in the gerber being left open which is apparently undefined in the spec. Actually I'm not sure why that would matter though - surely the only logical thing to do with an open polygon is to automatically close it? Maybe I misunderstood them.

Also that doesn't explain the bugs in the fast renderer.

I made a small gerber which illustrates the problem:

%FSLAX23Y23%
%MOIN%
G04 EasyPC Gerber Version 17.0 Build 3379
%ADD13C,0.00500%
%ADD98C,0.50000%
X0Y0D02
D02
D13
X53Y953D02
Y53D01
X953
Y953
X53
X240Y502D02
G75
G02X765I263D01
G01
G75
G02X240I-263
G01
X53D02
G36
Y53D01
X953
Y502
X765
G75
G02X240I-263
G01
X53
G37
X240D02
G36
G75
G02X765I263D01
G01
X953
Y953
X53
Y502
X240
G37
D02
D98
X502D03
X0Y0D02
M02*