X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <56A67B78.1090302@xs4all.nl> Date: Mon, 25 Jan 2016 20:46:00 +0100 From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] pcb_fprintf mixes mm and mils for same output object References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > This code: > > pcb_fprintf (FP, "\tArc[%mr %mr %mr %mr %mr %mr %ma %ma %s]\n", > arc->X, arc->Y, arc->Width, > arc->Height, arc->Thickness, > arc->Clearance, arc->StartAngle, > arc->Delta, F2S (arc, ARC_TYPE)); > > outputs this: > > Arc[176.6100mm 926.41mil 86.38mil 86.38mil 0.1540mm 0.3080mm -90 -90 ""] > > It looks intentional. The culprit code is in CoordsToString(): > > /* Check our freedom in choosing units */ > if ((allow& ALLOW_IMPERIAL) == 0) > family = METRIC; > else if ((allow& ALLOW_METRIC) == 0) > family = IMPERIAL; > else > { > int met_votes = 0, > imp_votes = 0; > > if ( coord[0] == 23530814 ) { > printf ("%s:%i:%s: checkpoint\n", __FILE__, __LINE__, __func__); > } > > for (i = 0; i< n_coords; ++i) > if(min_sig_figs(COORD_TO_MIL(coord[i]))< > min_sig_figs(COORD_TO_MM(coord[i]))) > ++imp_votes; > else > ++met_votes; > > if (imp_votes> met_votes) > family = IMPERIAL; > else > family = METRIC; > } > > So we're voting based on sig figs to decide whether to use metric or > imperial units. I wouldn't do this for the disk file format, if > anywhere. I guess maybe the intention was to maintain exactness in > case some objects were created with mil sizes and some with metric but > it's not worth it. > > There are other format codes besides %mr that force either metric or > imperial. I think for file format one of those should be used, or > else plain ints in the internal unit (nm). Fixing this is a file > format change though so I though I'd ask if there's any appetite for > or strong aversion to it. > > Britton > > Hi Britton, A nice find. I for one would like to hear the rationale for implementing in this way, best from the author (if possible) of the code under review. Kind regards, Bert Timmeman