X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=XSdhflV1HRFBeqZU5Mgmi3wLCPfWMDE8nXuJvhN7GAE=;
	b=qq4m71VOUbeVfeCfkol2NZ+HbQ/w+jaca0BwCOzMbii7bMhczxvm1vcBJA2u+qqkv6
	+KtJuNsfyPfLJg/7u0kJFvDq1Kav0tk3UkaIpxmPwmJ+qRD8x88nwi6iaR5qjRygxBBp
	gleFIs80ScEGmwQZyP0U10pJOB9AttrIsAjLfd6czZW244BkzrCsn9iSnlE1mDox2p0I
	/FBqnh4olI1r2eWl3WqpOIxOGX6hRJHFmItOFRW9uPW1AgXlbXAJmrj3BsoizSfLP6pr
	lKpSTDYlhM4qf1F0hVOVQkRoiXbZsSGvjheG2x6QCJwKGjwLsEmJ40BRfxty5A1nZNJn
	YvUg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:date:message-id:subject:from:to
	:content-type;
	bh=XSdhflV1HRFBeqZU5Mgmi3wLCPfWMDE8nXuJvhN7GAE=;
	b=ZTxT7cvDyBL5/chCYIi848AQbHHEa4YbWapiHzMUDfsLLp9AT8ArWDaGmqsSoCHn5H
	ZwGfwkfN92DpAgHGiuJQd1PuMz+ryGVltvl3YObxpjMt7Nxm/WFV+GfAxVrrubHWlWTg
	XXE7lCl0CYSwd036O1zMaJsivbvF3Jtw8HhYyRwG4GagZEZ6bYZRooWtDsEB+dAzmmPb
	wl0A0xFF0anm0G5DHhn1SsjYnR7Bc2wwozzNpj90x8JKUdaxBDsjQwq/nshrIZmhVoBA
	akXDAJZtUlz/s73hjMIoKdRr0D+CieE0Dk1CKKVDqgwC7vbu7Pgv2DZnz3g9i+KMbUUz
	qpTw==
X-Gm-Message-State:	AG10YORthZ83Fuf7uOV5cLBdoT2qTDMYK/ciuRJTrM9bmkiPZTlGRf856nGIyOIlBXI9J2eJmh8+JVP8dy5xAQ==
MIME-Version:	1.0
X-Received:	by 10.28.23.73 with SMTP id 70mr18949317wmx.37.1453747743259; Mon,
	25 Jan 2016 10:49:03 -0800 (PST)
Date:	Mon, 25 Jan 2016 09:49:03 -0900
Message-ID:	<CAC4O8c_ACXqSG7nC56a+GsTf0sy1_4+N5ivZU37X+mb92k+n1Q@mail.gmail.com>
Subject:	[geda-user] pcb_fprintf mixes mm and mils for same output object
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com

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

- Raw text -