- From: Christoph Päper <christoph.paeper@crissov.de>
- Date: Tue, 15 Apr 2014 17:14:43 +0200
- To: www-style list <www-style@w3.org>
fantasai <fantasai.lists@inkedblade.net>: > On 04/14/2014 05:32 AM, Christoph Päper wrote: >> Wow, I guess I should have explained better back in 2006 or 2009. > > I think one of the key points here was > "Although not many a designer uses these (yet or still), they should > be reasonably cheap to implement." > vs. a solid explanation that the unit is in common use today in non-CSS > applications, enough to warrant the implementation cost in CSS. Yeah, I have a history of making good points with bad explanation. I combine hardly related ideas in one proposal, get lost in too many side issues, forget to answer follow-up questions, point out counter-arguments without refutation etc. Nevertheless, there are more typographic units that are still being used outside CSS, mostly variants of “the” point. One is the point as used in Tex (~ 351 µm) which is slightly smaller than the PS/DTP point (~ 353 µm) that CSS chose to use. The latter is called “big point” ‘bp’, accordingly, in Tex. I believe their difference of about 1.3 µm or less than 0.4% is way too small to warrant a new unit, although its use exceeds that of kyu by far. I already mentioned another one in both mails cited before: The Didot point is specified close to 376 µm. It was used widely in Europe before the advent of DTP, which almost always is done with software designed in the US. (Insert pedantic note about Corel products being metric here.) I frankly don’t know how much it is still being used today, e.g. compared to ‘q’. That’s why I am (and was) the wrong person to propose it. The same goes for the cicero, its pica equivalent. If, however, someone did the research and found good reason to add it (or them) to CSS, I strongly believe it should be rounded to 375 µm, because that makes it more compatible with other units, has been done before elsewhere and differs from its original definition about as much as the English points differ from each other. The 400-µm “French point” is probably used even less since it wasn’t as popular before. On a related matter, CSS could allow or even recommend integer arithmetic for length values. It just would have to introduce the “English Metric Unit” from Microsoft’s XML office document format, which is the greatest common divider of point and millimetre. 90 emu/q, 127 emu/pt, 135 emu/dd, 360 emu/mm, 1524 emu/pc, 9144 emu/in Except that this would require another factor of 3 to work well with CSS pixels: 270 i/q, 381 i/pt, 405 i/dd, 508 i/px, 1080 i/mm, 4572 i/pc, 27432 i/in That “i” is of course very close to a micrometre (ASCII symbol ‘um’), so that could be used instead as an integer base, but would require rounding again, i.e. the current relationship of units would have to change somewhere. Metric units, incl. Q and Didot point, must keep their real-world value in relation to the CSS micrometre. 250 µm/q, 375 µm/dd, 1000 µm/mm Now, you could either break the (more or less) odd centimetre-inch relation (2.54) or the even point-inch and pixel-inch ratios (72, 54), probably also the arbitrary point-pixel correspondence (4:3). nice numbers: 350 µm/pt 469 µm/px 25200 µm/in 1.34 pt/px 72 pt/in round down to 3: 351 468 25272 1.(3) 72 pt/in round down pt: 352 469 25344 1.33238… 72 pt/in round (down) px: 353 470 25380 1.33144… 54 px/in round down all: 352 470 25400 1.33522… odd ratios round all: 353 470 25400 1.33144… odd ratios round up all: 353 471 25400 1.33427… odd ratios round (up) pt: 353 470 25416 1.33144… 72 pt/in round up px: 353 471 25434 1.33427… 54 px/in round up to 3: 354 472 25488 1.(3) 72 pt/in Not worth the hassle (nor the hoff). The “i”-unit is the only viable one of these. A signed 32-bit integer could hold length values up to almost 2 km; uncommon 24 bit integers would be enough for most if not all applications of CSS.
Received on Tuesday, 15 April 2014 18:09:11 UTC