On Tue, 06 Nov 2012 13:00:36 +0100 Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
I don't understand why there should be specific code to handle metric units.
It is a different kind of "metric" :) (Think measure instead SI units.)
Well, colour me corrected.
Surely the simplest thing to do is have the ratios between various real-world units defined in the "units.txt" file, and then have the "Default units" option from the "Document Properties/Page" dialog specify which one of those will be considered equivalent to "px" for purposes of that document.
Nobody said it is particularly difficult, but it does take time. Of course, if you're volunteering, I couldn't be happier :) (As would a whole lot of other people.)
Could you tell me what is the significance of the current "units.txt" and "units.xml" files?
As I said in my initial post, the influence of "units.txt" seems to be less than total, and that of "units.xml" is apparently nil.
Systems of related units, with integer ratios between them, such as inch/foot/yard/mile, and um/mm/cm/m/km, could be treated as a special case. Then specifying the ratio between any pair of them, such as 1.0 inch = 0.0254 metre , also determines all the other ratios. Having all such units specified in a config file eliminates the need for code changes when somebody wants to introduce new ones.
Actually, something like that might indeed make sense. Perhaps it would then make most sense to simply split the definitions of the units themselves and the relationships between them. Conversion between two units would then only be possible if there is a path of conversion rules between them.
That's what I was thinking of, except that you still have to define the units in terms of something else. I propose that the "units.xml" format be extended to handle hierarchical definitions, and ratios, as I suggested in my previous post. For example:
<unitdefs> <linear>
<unit factor="1.0"> <name>metre</name> <plural>metres</plural> <abbr>m</abbr> <description>Metres (SI base unit)</description>
<unit factor="1/1000"> <name>millimetre</name> <plural>millimetres</plural> <abbr>mm</abbr> <description>Millimetres (1000 mm/m)</description> </unit>
<unit factor="1/100"> <name>centimetre</name> <plural>centimetres</plural> <abbr>cm</abbr> <description>Centimetres (100 cm/m)</description> </unit>
<unit factor="1000"> <name>kilometre</name> <plural>kilometres</plural> <abbr>km</abbr> <description>Kilometres (1000 m/km)</description> </unit> </unit>
<unit factor="0.9144"> <name>yard</name> <plural>yards</plural> <abbr>yd</abbr> <description>International Yards (0.9144 m/yd)</description>
<unit factor="1/3"> <name>foot</name> <plural>feet</plural> <abbr>ft</abbr> <description>Feet (3 ft/yd)</description>
<unit factor="1/12"> <name>inch</name> <plural>inches</plural> <abbr>in</abbr> <description>Inches (12 in/ft)</description> </unit> </unit>
<unit factor="1760"> <name>mile</name> <plural>miles</plural> <abbr>mi</abbr> <description>Miles (1760 yd/mi)</description> </unit> </unit>
</linear> </unitdefs>
Here, the relationship between Metric and Imperial units is implicit in the ratio [1/1.0 metre : 1/0.9144 yard]. Other unit conversions must follow the path through the hierarchy, as you suggest. If a top-level unit definition does not specify a conversion factor, then there will be no possibility of converting units from that hierarchy to those from another, which is perfectly OK.
Any other units that people wish to use (angstroms, picas, nautical miles, light years, etc) can simply be inserted into this tree, at either the top level, or a subordinate one. "px" units will not be defined here; they will be considered equivalent to whatever is selected as the "Default unit" for the document.
-- Ian Bruce