X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 5 Jul 2012 10:34:23 -0700 From: Andrew Poelstra To: geda-user AT delorie DOT com Subject: Re: [RFC, v2] [geda-user] [PATCH] Allow to create metric Gerber and drill files. Message-ID: <20120705173423.GC12804@malakian.lan> References: <20120703140236 DOT GA12646 AT visitor2 DOT iram DOT es> <20120705101614 DOT GA19974 AT visitor2 DOT iram DOT es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120705101614.GA19974@visitor2.iram.es> User-Agent: Mutt/1.5.20 (2009-12-10) 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 On Thu, Jul 05, 2012 at 12:16:14PM +0200, Gabriel Paubert wrote: > > I have appended a second version of the patch; the only difference > with the first one is that now the line in the header that starts > with "G04 PCB-dimensions" now specifies the dimensions either in > metric or in imperial dimensions depending on the metric option. > > I was expecting that the developers with git write access > would be a bit more reactive and tell me whether something > looked wrong with the patch. I must admit I'm not completely > satisfied with the names of some functions/variables, but I'm > not too worried since they are local to the gerber.c file. For > global names, I'm much fussier. > The patch is as well-done as it could be. I considered doing it a while back, but was turned off by all the if-statements necessary. Thanks for finally biting the bullet! Unfortunately, I don't recall enough about the Gerber spec to review your patch, nor to address your other concerns. I might push it through when I get a free moment anyway, assuming it doesn't break the old behavior. > From my limited tests, the patch does not affect the Gerber > code in imperial mode (diff output only lists the obvious: > timestamp in the header, and the board dimensions in the > second version of the patch, in any case only the comments > are affected). > Does tests/run_tests.sh still pass? > Now there is still one thing I question: it is the logic > that generates the aperture code. A long time ago, pcb reused > aperture codes between layers. Now it uses a separate aperture > space for every layer, which does not make much sense to me. > > Especially troublesome is the fact that the drill size numbers > are extracted from the same space as the aperture numbers, which > leads to unnnecessarily large numbers: in my last board I have > drill numbers 100, 101, and 102. However, the description of > tool selection from http://www.excellon.com/manuals/program.htm > indicates that you should not have more than 2 digits, since > when there are more than 2, the last two are interpreted as a > "compensation index", whatever that means (it's not my domain). > Gerbv interprets the tool definitions as I want, but it might > be a bug which results in a DWIM behaviour. > > My conclusion is that at least the drill bits should be defined > starting from one. For the photoplotter layer, I'm still unconvinced > about the convenience of the current behaviour. > > Of course, this is open source, so why not make it configurable? > The three options would be: > 1) start from D11 for each layer (overlapping spaces), > 2) use a single global aperture space (reusing the same apertures > codes on different layers) > 3) use non overlapping aperture spaces (current behaviour) > > Question to developers: would a patch that fixes the drill bit > numbering problem described above be considered for inclusion? > I would expect so. I don't like the huge drill numbers for purely asthetic reasons. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "You shouldn't trust every quote you read on the Internet." -- Socrates