RE: font-size-adjust in CSS3 Fonts module

From: L. David Baron [mailto:dbaron@dbaron.org] 

>> -          It is Latin-centric, and not readily applicable to most scripts.
>
> It's more than just Latin -- there are a number of other bicameral scripts, including Cyrillic and Greek.

Not that many: Armenian, Coptic, Cyrillic, Deseret, Georgian, Greek and Latin. The number of scripts for which it is not useful is far, far longer.


> It it intended to be used only where appropriate, i.e., with documents in bicameral scripts.

Clearly. But a different approach could deal with the same scenarios and many more besides.


>> Even for Latin text, I think the design of the property is problematic. The idea of matching x-heights is conceptually simple and at first glance seems a reasonable approach to get a good size match. But using the property requires the Web developer to figure out a specific ratio of two particular values in a font, neither of which is directly available to a Web developer: the x-height divided by the font units per em. Because the specific data isn’t readily available, the documentation describes a trial-and-error heuristic approach to understand the values for a given font: formatting two spans of text and tweaking the font-size-adjust value on one of the spans until they match. It’s awkward enough to lead people to start publishing tables for known fonts—an approach that’s fine if we expect the typography of the Web to remain limited to the same small set of fonts that have been widely used in the past, which of course is not the desired course for the future.

> I don't think this is true:  an alternative way to look at how the property works is what I described in http://dbaron.org/log/20080613-firefox3-css :
>  # the way I like to think about it is that is a way for style
>  # sheets to pick font size by the size of the x-height rather than
>  # the size of the font.
> It's just a way to do this that is backwards-compatible with browsers that don't support it.

Your description seems like a good way to think of it. And I found this description much clearer than what's described in the Fonts draft. However, this doesn't address my comments, which was about how a developer determines what value to set. That can only be done in one of four ways: (i) you have font tools and know exactly what data in a font to read (unitsPerEm in the head table, and sxHeight in the OS/2 table), (ii) you craft a test page with two spans and tweak values by hand in a trial-and-error fashion (the method described in the spec), (iii) you find some table with values for known fonts that someone has published (which doesn't help if you want to use any font not in that table), or (iv) you find someone who has crafted some tool just for this purpose.


>> There’s a different approach that could be taken to all of this: for different fonts in a font stack, allow the developer to indicate a scaling factor—a percentage coefficient to apply to the nominal font size when that font gets used. Advantages that this would have include:

>This requires *much* more work on the part of the author.

It requires the author to set additional values for the other fonts. I don't see that that's *much* more work, and it's far easier to work out values you'd want to use than to figure out the true "aspect value" of a font. And, it enables many more scenarios.


>> In thinking about the behaviour of font-size-adjust and scenarios in 
>> which it would be used, I find David 
>> Baron’s discussion enlightening...

> I was referring to a technical issue with Gecko browsers...

Fair enough. But in your discussion, you ran into the issue of width of characters being another factor besides the x-height, and IIUC you kept tweaking to get a result you liked rather than using the property in the particular manner that was intended.



Peter Constable

Received on Tuesday, 3 May 2011 15:53:47 UTC