Re: [CSS21] last edition: pity

2009/5/11 John Daggett <jdaggett@mozilla.com>:
> Hi Thomas,
>
>> Maybe I'm missing something, but isn't all this font weight stuff kind
>> of meaningless given that the notion of "family" is
>> undefined/platform-specific, and the same set of fonts can and will be
>> one family on Mac and several families on Windows GDI?
>>
>> That is, on Mac (and in Windows Presentation Foundation), you can have
>> a very large number of different weights in one family. As a practical
>> matter, in GDI you can have only two, a "regular" and a "bold." (Yes,
>> technically you could have more, but since about half of all GDI apps
>> would deal badly with the multi-weight family, including Microsoft
>> Office, nobody makes such fonts.)
>
> You've actually brought this up before back in March and I responded
> with details then:
>
>  http://lists.w3.org/Archives/Public/www-style/2009Mar/0041.html
>
> We also discussed the topic of style linking at the March F2F, the
> discussion is in the section "Grouping fonts into font families":
>
>  http://lists.w3.org/Archives/Public/www-style/2009Mar/0070.html
>
> The simple answer to your question is that the CSS font model is
> font-format agnostic, it is not specific to OpenType/TrueType fonts, it
> simply defines a set of commonly used font property axes (i.e. weight,
> slant, width, etc.) and a process for selecting a face based on these
> properties.  Obviously OpenType/TrueType fonts represent the vast
> majority of fonts that are used in user agents today so it's crucial
> that user agents handle style linking of platform fonts consistently.
> The underlying problem is not just GDI but the OpenType specification
> itself, which defines family linking differently for Mac vs. Windows
> (i.e. Mac uses just the 'family' name record whereas Windows uses
> several different name records and explicitly enforces a restriction of
> just four faces per family name record on Windows but not on Mac!!).
>
> >From the March post:
>
>  So the question boils down to "how do we get richer font family
>  groupings on Windows?".  I think the answer to that is that user agents
>  on Windows need to move towards grouping font faces by "Preferred
>  Family" if it exists, which means pulling data out of font tables.
>  Current versions of Windows don't ship with extended font families so
>  this really only affects folks who have installed fonts or use Adobe
>  apps that install extended font families.
>
> Along with the Mac, font families created with @font-face are
> specifically *not* subject to these funky family grouping restrictions,
> so font weight can be used to reference all available Helvetica Neue
> faces under Mac OS X and can be used to reference all seven weights
> of the open-source M+ font family via @font-face rules:
>
>  http://people.mozilla.org/~jdaggett/mplustest.html
>
> The above test page as rendered in Webkit, FF 3.5 beta:
>
>  http://people.mozilla.org/~jdaggett/mplustest.png
>
> Even when only two faces are available, the spec still needs to define
> how bolder/lighter work when nested, as other have pointed out.

I thought about it after my last email on this topic. If I understand
it correctly, the problem with simple numeric behavior is that
<span style="font-weight:normal">A<span
style="font-weight:bolder;">B<span
style="font-weight:bolder;">C</span></span></span>
B computes font-weight to 500, C computes to 600, but the selected
font has only 400 (normal) and 700 (bold). So the font matching
algorithm selects 700 for both. This means that C is not bolder than
B.
I can imagine two solutions to this:
- change the font matching algorithm to synthetic bolding for
everything different than 400 / 700, not just everything less than 400
/ greater than 700
- set bolder = inherit +200 instead that +100
in the example, B computes to 600 and C to 800. B uses the 700 face, C
uses synthetic bolding. This is the current behavior, but without
magic for bolder/lighter.

I would prefer the second option, along with the CSS3 Font matching algorithm.

Giovanni

Received on Monday, 11 May 2009 12:01:50 UTC