I fully agree that there are many aspects of the RS274X specification that leave a lot to be desired, but I'm still not convinced of the merits of totally forsaking the use of Aperture Macros and Polygon commands.
The copy of the RS274X standard which I have (an Acrobat file which I downloaded from a website some years ago) makes no specific reference to being able to use Arc commands in conjunction with Polygon commands, so I concur that it would be desirable to avoid using that combination. And I also think that it would be highly desirable to avoid incorporating different layers within the same Gerber file (re using both "dark" and "clear" polarities). But I think that totally avoiding the use of Aperture Macros could be taking things too far. As long as the value of each parameter (for each primitive that is used within an Aperture Macro) is explicitly defined, and no "algebraic substitutions" are required in that regard, I would regard the usage of Aperture Macros as acceptable (assuming that no attempt is being made to "push the limits" of the RS274X specification at the time). A really "extreme" view of Gerber files is that they should *never* incorporate *any* Arc commands either, least some PCB manufacturers not be able to cope with them. Would you advocate that as well? I have not really looked at the source code for generating Gerber files so far, but when I get a chance, I will take a look and see if there are any aspects where improvements could be made to at least reduce (and preferably totally eliminate) the possibility of Gerber files' contents ever being misinterpreted. In that regard, I would regard it as preferable to use an Aperture Macro (incorporating a type 21 / "centered line" primitive) to define an aperture for a pad having a rectangular shape on a non-orthogonal angle, rather than using a Polygon command, and there could well be various other aspects which could also be improved. And maybe something else which should be considered at some stage is providing the feature of generating (sets of) ODB++ files from PCB files. While I am not currently an expert on such files, it is still my understanding that they don't suffer from the shortcomings that afflict Gerber files (due to the shortcomings of the RS274X standard). However it is also my understanding that many PCB manufacturers are not yet equipped to handle such files, and I gather that some of them haven't even heard of such files. But doubtless any PCB manufacturers who actually can cope with such files would still prefer to receive them whenever that is possible. Regards, Geoff Harland. "Robert Kondner" wrote: > > Hi, > > That RS-274-X spec has more holes than Swiss Cheese. > > For example: If you start a Poly Fill and use a ARC I guess the > ARC becomes part of the the poly edge, correct? > > Doing so results in a polygon with circular voids. This is a huge > area for "Interpretation Errors" in gerber processors. Now add to > the fact that these polygons could be in clear or dark areas of a > single layer and the multiple layers COULD be combined. Good luck > finding 2 gerber processors that render this to the same film image. > > Chance are about 5% that you get a call from the PCB vendor. > Chances are 95% that you get back a bad PCB. Worse yet the location > for finding errors in circular voids is in an internal plane. > Shorts in a plane are like an unforgivable sin, nothing can save > you. > > After many years of doing PCB designs and the writing of a gerber > reader (MUCH more difficult than writing gerbers) my suggestion is > Keep It Simple (KISS Solution). > > The generation of gerbers and their resulting rendering to film > must be ABSOLUTLY PERFECT. We live and die by this level of > perfection. To achieve this level of perfection think of a gerber > as a vector driven bitmap. No Aperture Macros and no Polygons need > to apply. Even if 99% of the code in the industry reads and > processes PERFECTLY that 1% is a reason NOT to use them. > > We need ROCK SOLID routines for flattening a higher level > structure of shapes. The output is a set of scan lines that paints > the required image. > > I write in Delphi, I can easily generate .dlls, and the resulting > scan lines could convert directly to KISS generation of gerbers. I > have a simple gerber reader that is used to read from LOTS of > different apps. It took years learning what liberties every app > programmer could take with gerber generation. Lets NOT to the same > thing in DRIVING film plotters. > > Summary: > > We live or die with gerber generation. If we even need to talk to > a fab house about gerber processing we are dead meat. > > I would love to see a solution got this gerber generation issue. > > Thanks, > > Bob Kondner
