Agreed 90%. I don't have so much of a problem with "fixing" the dimensions as long as they're only fixed in the Gerber export, not in the master - it's just part of exporting, you're rendering things with the features available to you in the destination format. But that's a minor point, obviously I don't want to turn the alternative units back on if they don't work. I wasn't aware of this problem.
On Wed, Aug 05, 2015 at 10:56:02AM -0400, Wayne Stambaugh wrote: > > > On 8/4/2015 3:03 PM, jp charras wrote: > > Le 04/08/2015 08:29, Lorenzo Marcantonio a écrit : > >> On Tue, 04 Aug 2015 05:38:26 +0200, > >> Chris Pavlina wrote: > >>> > >>> pcbnew used to be able to plot Gerbers in imperial units. What happened > >>> to that? Some (particularly older and non-Asian) board houses still > >>> expect those... Is there any reason they were removed, or did they just > >>> "fall out"? And can they be put back in? > >> > >> Since the new plotting infrastructure the gerber plotter already > >> supported both units; the IN was simply the compatibility default and it > >> only needed an UI option to be bound. > >> > >> If someone changed the default without adding a radio button or > >> something then blame to him:P > >> > >> AFAIK there would be no technical reason to not do inch plotting... > >> > > > > There is a technical reason to not do inch plotting. > > I recently explained it. > > > > Pcbnew internally uses nanometers, corresponding to 6 digits mantissa in > > Gerber. > > > > If we use a 6 digits mantissa and mm in Gerber, there is no rounding issue. > > If we convert these values to inches, I am pretty sure rounding issues > > will appear. > > > > For most of coordinates, a rounding issue has no matter. > > However, for complex polygons (copper zones) rounding coordinates can > > create self intersecting polygons from non intersecting polygons. > > Self intersecting polygons are not allowed in Gerber files (see gerber > > file format spec). > > > > The advice from Ucamco is (especially for this issue) is: > > use the max resolution for coordinates (see also the gerber file format > > spec). > > > > > > The only one reason the 5 digits mantissa option exists in Pcbnew is the > > fact Ucamco told me a few Gerbers tools do not accept the 6 digits. > > > > I verified some Gerber files which are OK with 6 digits mantissa create > > self intersecting polygons when using 5 digits from the same board. > > (Tests with GC-Preview) > > > > (to tell the True, the Gerber image on screen was the same) > > > > We already have a bug report about self intersecting polygons in Gerber > > files from Kicad. > > > > It also explains why a Gerber reader can gives warnings about that > > issue, and an other Gerber reader does not find any issue: it depends > > also on internal units of the reader. > > > > > > Therefore, until someone give me a *very good reason* why inches are > > better than mm in Gerber files, I *do not want* a inch option in Gerber > > plot menu ( or, if this option exists, commit an algo to avoid self > > intersecting polygons). > > > > I'm going to side with JP on this one. Simply enabling the conversion > from the internal nanometer units to inches for gerber plotting is not > an acceptable solution no matter how harmless it may seem on the > surface. The combination of loss of precision and the floating point > rounding errors can potentially lead to self intersecting polygons as JP > has mentioned. Whether or not these errors are significant is design > dependent. It's most likely that they would not result in an issue for > most designs but I would rather error on the side of caution on this issue. > > Any solution to this problem must include an algorithm to detect and > potentially correct the problem. The issue I see with this is the > correction algorithm. Programmatically fixing the self intersecting > polygons when they occur may or may not be what the user intended. The > question then becomes what to do about. One option is to warn the user > and tell them to fix the offending object dimensions. Another option is > to fix the offending object and warn the user of the change. I would > oppose silently fixing the offending objects without the user's knowledge. > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp