96 pixels (SVG user units) per inch is defined by CSS:
http://www.w3.org/TR/css3-values/#absolute-lengths
On Fri, 2014-09-19 at 10:12 -0700, mathog wrote:
On 19-Sep-2014 05:11, Tavmjong Bah wrote:
On Thu, 2014-09-18 at 09:50 -0700, mathog wrote:
After some consideration it seems to me that the viewbox coordinates should come out to 96dpi no matter what the physical length units are.
I am sympathetic to this view and that was my initial thinking before discussing it inside the SVG working group. It certainly has the advantage that the use of absolute units ('in', 'cm',) inside the SVG works as naively expected. But there are two disadvantages:
- To get exact metric values of length you must include units such as
'2mm'. We would need to add this ability to Inkscape.
If "exact" means "terminates nicely in a digital representation" then we could also use a value like 127 dpi, which is 25.4 * 5.
127 * 2 / 25.4 = 10.0 # 2 mm to user units 25.4 * (10/127) = 2 # user units to 2 mm.
Let's see, is there something closer to 96? 25.4*4=101.6 has similar properties. Let's factor 254, and maybe get a little more wiggle room, that is 2 * 127. So this should work well too 25.4*3+12.7 = 88.9. (Numerically 101.6 and 88.9 might have problems, because while the base 10 representations are nice, the base 2 representations are not.)
101.6 * 2 /25.4 = 8.0 88.9 * 2 /25.4 = 7.0
For fractional inches it is a little ugly, adding a couple of digits beyond the decimal, but at least it doesn't run off to an infinite number of base 10 digits:
1.5 * 88.9dpi = 133.35 # 1.5 inches
88.9dpi is very close to the original 90dpi, but of course 90 doesn't have this numerical property even for base 10.
90 * 2 / 25.4 = 7.086614173228...
Using common factors like this gets messy if have to add more representations, but we should probably also add the point, since that is used for fonts. A point is 1/68th of an inch, and 68 is 4 * 17. So ignoring factors of 2, because they only add one or two digits after the decimal place, 12.7 * 17 = 215.9.
215.9 * 2 / 25.4 = 17.0 # 2mm 215.9 * 2 = 431.8 # 2 inches 215.9 * 2 / 68 = 6.35 # 2 pt
We should probably make this dpi value nice in both base 10 and base 2. To do that it would be 17 * 127 = 2159 dpi, or possibly that number divided by some power of 2. None of those come very close to 96 though, 134.9375 and 67.46875 are the closest, but they have enough digits that we could lose precision on multiplication with 32 bit floats.
So maybe 2159 dpi is the magic number?
Why are we trying to use 96? It seems like a pretty arbitrary number. Although I vaguely remember that Batik defaulted to that.
You know, all of this shows why it would be pretty useful to let all length/coordinate values specify a physical unit. At present that is uncommon, but Font-size allows that. If it did not having a user unit that was metric would result in awful values for the font-size, which are usually specified in points. If length/coordinate values had physical units there wouldn't be much reason not to lock the user unit at some arbitrary value (96 or 90 or whatever), because at that point what some of you are trying to accomplish implicitly with all of this user unit code would then be explicit in the SVG. And it would support mixed physical units, which the present approach (full conversion on every change of default units) does not.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel