kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

В сообщении от Четверг 23 июня 2011 05:09:39 автор Dick Hollenbeck написал:

> I still agree with Lorenzo, Alex, and the factors that led to this posting
> back here:
> 
>   https://blueprints.launchpad.net/kicad/+spec/unit-system
> 
> 
> which I personally asked Alex to do, just to get it documented.
> 
> Simply changing the internal unit to a new fixed quantum is the best path
> in my opinion.  From there you only need 2 scaling factors to generate
> mils or your most preferred metric unit.

I do not pretend to change this in any way. My class is just a wrapper to do 
the conversion in nice way, and help to trace all the length quantities.

> 
> Vladimir, I don't know if you are proposing working with alternate sets of
> internal units.  If so, I think that is unnecessary and probably a
> difficult path.

No, I do not want to do it. However on half-way of conversion there would be 
'old' (in ints) and 'new' (in LENGTH class) units together. When conversion is 
done old should be gone.

> 
> > But IMHO it should be done *together* with the new file format so to
> > have only one format conversion to do... i.e. traditional kicad in
> > decimils and SWEET/sexp/whatever in nano units...
> 
> Regarding the file format issue, I see no reason why the current file
> formats cannot be tweaked to support metric or imperial.  So I disagree
> with Lorenzo on this.  No reason to wait.  I see a need for only two units
> in the file PCB formats:
> 
> 
> 1) Imperial.  The blueprint says 1/100th of a mil.  But I would argue
> adding a decimal point to the numbers, and simply saving them as mils in
> files.  I do not think we'd have to use exponents, simply numbers with
> decimal points.  Such as 70.378 (mils).  Exponents are not desirable.
> 
> (See below for why a decimal point is helpful in the files.)

> 2) Metric.  Somebody pick, if a decimal point is used in the number, it can
> even be millimeters.

I see only the problem with decimal separator: it should be handled carfully:
parsed manually, or first converted to FP number with high precision, then 
converted to inernal storage.

If it helps keep backward compatibility, would be fine if saved unit will stay 
the same. (E.g. 1575.4475 decimils old version should read as 1575, and new in 
full precision)

> 
> 
> Each PCB file type can name which of the two units it is using (with
> perhaps a third being what we have now).  On file loading, these numbers
> can be converted to the 1 nanometer internal unit without error or any
> rounding, exactly.
> 
> On file saving, things are a little different.  Because you have such fine
> granularity in the 1 nm internal unit, converting to say 1/100th of a mil
> *whole number* cannot be done without some rounding.  To avoid the
> rounding on the conversion in this direction, we can use a decimal point
> in the numbers saved within the PCB files.  If this is done, then I see no
> problems with my plan, somewhat modified from the blueprint.
> 
> Dick
> 

I do not ever see a need to keepmore than one unit supproted. If you convert 
nm to decimils with 1/10000 precision it would read back to nm fine, without 
any loss (however this thick shoul only be done on files, not in any internal 
computation)

In SWEET we can choose any unit we like (even fractional meters).
-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61