Mailing list archives : pcb-rnd

ID:59
From:ge...@igor2.repo.hu
Date:Sat, 3 Sep 2016 17:27:47 +0200 (CEST)
Subject:Re: [pcb-rnd] pcb issues: grid
in-reply-to:58 from Chris Smith <sp...@icloud.com>
replies: 61 from ge...@igor2.repo.hu
 
 
On Sat, 3 Sep 2016, Chris Smith wrote:
 
(History/terminology: back then I forked from the 2011 version (last 
stable release of mainline. There's also a 2014 public snapshot available, 
then the numerous git branches.)
 
 
> Have I missed something? I thought pcb mainline switched to nanometres some time ago, so why is it even using mils?
 
Yup, it did. It's still using mils & centimils in the .pcb file format in 
some fields, in some versions.... It's a mess. I've been tracing this back 
to the last stable release (2011) to make sure I don't mess up 
compatibility.
 
First, there's the old .pcb format and the new .pcb format. The old was 
probably used between 2007 and ~2010. It has () for blocks. The new got 
(probably) introduced by the time they did the nanometer transition and it 
uses the [] for blocks. The file loader handles both, but the writer emits 
only the new format. So pcb-rnd and mainline are not going to be 
save-compatible with the old (pre-nanometer?) versions.
 
In theory the loader accepts values with units, so if you write 1 mm or 1 
inch in the file, it's 1 mm or 1 inch, without rounding errors. On the 
input (after my last fix) this is even true - this bug I fixed is 
still present in the 2014 snapshot (I don't know about git versions).
 
In the format, another option is to write a number without unit, which is 
then interpreted as centimils. You generally wouldn't do this. 
Unfortunately the whole file write code insist on writing the unitless 
centimil numbers using %mr - as integer! This is the main reason why a 
full round trip (save a proper pcb then load it again) introduces rounding 
errors whatever the load code does.... And this is why it happens to mm 
values, and not mil values. And yes, this is like that in the 2014 
snapshot too (still no idea about git).
 
> Did pcb-rnd fork before this?
 
Nope, it's all inherited stuff - until today I didn't change anything in 
the .pcb file format or pcb-printf implementation regarding to these.
 
Tested mainline-2014, it does have similar rounding errors on your files. 
Mainline git may have come up with a fix for this since 2014, I'm not 
really following that.
 
 
Now, the important part: how I am fixing it.
 
01. In theory we could write using %mI, which is the internal unit, which 
is nm. We won't do this, because this has two big disadvantages: it 
exposes the internal units, so if we ever need to switch again, we break 
the file format (or have to update the writer code again); the bigger 
problem is that it's absolutely not human readable. This would be an 
unitless integer value, which would also confuse mainline loaders which 
would think it's in centimils - as long as they want to be comaptibible 
with the mainline version from the past few years...
 
02. We could insist on using the centimil format with enough decimal 
digits that it doesn't break. I have no idea to what extent it would break 
compatibility... I think it would cause the same rounding error with the 
2014 version, as it would use the integer version after loading the value. 
But if we change anything, we should probably change to something more 
natural/readable than centimils... So this possibility is out.
 
1. There's a %$mS format, which always prints the unit and uses the "most 
natural" unit; this means it keeps 1 mm as 1 mm and 1 inch as 1 inch. If 
you have something like 1.123456 mm, it's somewhat "random" whether it 
ends up as mm or mil, depending on which one gives the saner output. We 
should use this. But...
 
2. By default, it prints only for 2 decimal digits, which in turn leads to 
precision lost - don't ask why, it's still inherited code. So the proper 
variant would be %6$mS - just enough digits to represent the smallest 
increment the core can handle in any appropriate unit. In other words, 
this length would guarantee we don't introduce errors by writing a value. 
But...
 
3. I don't want to see "1.000000 mm" all around. Especially if we already 
use "natural unit" so we most often end up with real round numbers. So I 
added a new feature in pcb-printf: %06$mS does the same as %6$mS, but also 
truncates excess trailing zeros, so 1 mm ends up as "1.0 mm".
 
4. Now this would be almost good enough, but this whole topic is risky: 
with the slightest wrong move we could break the file format and lose 
save-compatibility with whatever version of mainline a new pcb-rnd user 
would switch from. I am pretty sure the first time an user can't load a 
pcb-rnd edited .pcb in mainline, he loses all trust in pcb-rnd. So instead 
of just replacing the original "file format mandated" %mr, I am going to 
provide different .pcb file format options on save:
 
A. a natural unit .pcb; this would be the default .pcb long term. It would 
save using %06$mS; as far as I can tell, this would work with any mainline 
starting at least from 2011. This uses unit suffixes and "random" units.
 
B. a "compatibility" .pcb, which uses the current %mr, just in case 
someone really has a version from between 2010 and 2011 that doesn't 
handle units correctly on load. This means no unit suffixes and everything 
in centimil.
 
C. a nanometer unit .pcb; this would use nanometer for all numbers with 
unit suffixing. We need this because we lose easy script-processing with 
A.: your external scripts would need to understand like 9 different pcb 
units, and if the unit list is extended in pcb, all scripts would need to 
be upgraded too.... Instead, if you know you are going to feed a script, 
you could just use nanometers and lean back. (Note: other users have been 
complaining on the ML about mainline and script processing and solution 
A., so I'm not the only one worrying about this. In this, we'll be a bit 
more advanced than mainline, where you can't choose this runtime, afaik).
 
5. new export or IO formats, like lihata board, will probably have option 
A. and C. for the same human-read vs. script-processing reasons.
 
I believe I will be able to finish all these this weekend.
 
Regards,
 
Igor2
 

Reply subtree:
59 Re: [pcb-rnd] pcb issues: grid from ge...@igor2.repo.hu
  61 Re: [pcb-rnd] pcb issues: grid from ge...@igor2.repo.hu
    62 Re: [pcb-rnd] pcb issues: grid from Chris Smith <sp...@icloud.com>
      64 Re: [pcb-rnd] pcb issues: grid from ge...@igor2.repo.hu