Re: [css-fonts] More granularity for font-weight?

Hi Kenji,

I think it would be fine to extend the set of available font weights in
CSS. But I would caution that there are some nasty gotchas related to the
font weight values that are stored in fonts and in some platform API's that
provide this data to user agents. Simply allowing a wider range of weight
values won't allow for consistent matching of font weights on all platforms.

The first issue here is the "GDI synthetic bold" problem. Under Windows,
the GDI font API's will automatically apply synthetic bolding to any font
with a weight of 200 or below. Font designers have worked around this by
avoiding weights under 250 when shipping fonts for Windows (e.g. Roboto,
Noto Sans CJK). That's why a "Thin" face is given a weight of 250 rather
than 100 as suggested by the OpenType spec [1].  See also this typophile
discussion [2]. The result of this is that weight values at the lower end
of the scale are inconsistent across font families, some are skewed to
avoid the GDI problem, some not. If an author wants to specify a Thin face
across families, sometimes 250 will be the ticket, sometimes 100. This
probably requires some sort of OpenType spec solution (e.g. extra bits that
indicate a skewed or absolute scale for weight values).

The second issue is that platform API's don't always do a good job of
reporting weight values in any sane manner. OSX font API's don't always
report font weight based on the OS/2 value, there seems to be some sort of
interaction between the usWeightClass value in the OS/2 table and the
weight that can be inferred from the style name (e.g. "Thin"). See lots of
gory details in this bug [3]. For example, the Avenir font family has
'Heavy' and 'Black' faces for which OSX platform API's report the *same*
weight value, even though the weight value indicated by the font data is
different (see below). This is a platform bug for OSX.

> Should the restriction on font-weight be relaxed?
>  - all positive integers?
>  - all integers between 100 to 900?
>  - add 50 increments between 100 to 900?

I think the value should be all integer values in the inclusive range [1,
999], which roughly aligns with what's allowed by DirectWrite (the OpenType
spec doesn't precisely define the limits).

It would be relatively simple to extend the existing font matching
algorithm to cover the extended set of font weight values. Naturally,
current user agents won't recognize all values (e.g. 250).

I also think it would be better to make these changes in the CSS Fonts 4
spec. ;)

Cheers,

John Daggett

[1] http://www.microsoft.com/typography/otspec/os2.htm#wtc
[2] http://typophile.com/node/84518
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=931426

Avenir OSX 10.9
columns: appKitWeight css(appKitWeight) os2-usWeightClass CoreText-weight
psname family
3 200 300 -0.40 Avenir-Light [Avenir]
3 200 300 -0.40 Avenir-LightOblique [Avenir]
5 400 400 0.00 Avenir-Book [Avenir]
5 400 400 0.00 Avenir-BookOblique [Avenir]
5 400 400 0.00 Avenir-Oblique [Avenir]
5 400 400 0.00 Avenir-Roman [Avenir]
6 500 500 0.23 Avenir-Medium [Avenir]
7 600 500 0.23 Avenir-MediumOblique [Avenir]
11 800 800 0.62 Avenir-Black [Avenir]
11 800 800 0.62 Avenir-BlackOblique [Avenir]
11 800 900 0.62 Avenir-Heavy [Avenir]
11 800 900 0.62 Avenir-HeavyOblique [Avenir]



On Thu, Jan 8, 2015 at 1:27 PM, Kenji Baheux <kenjibaheux@chromium.org>
wrote:

> Hi,
>
> Currently CSS font-weight can take a few fixed number values: 100, 200,
> 300, ..., 900
>
> It was brought to my attention that fonts with intermediary font-weights
> seems to be more common lately:
>  - Roboto and Noto Sans CJK have a 250 thin font variant
>  - Apparently Windows has been shipping with 350 semi-light fonts for
> quite a while now:
>     - LeelUIsl.ttf: Leelawadee UI Semilight
>     - NirmalaS.ttf: Nirmala UI Semilight
>     - segoeuisl.ttf: Segoe UI Semilight
>     - seguisli.ttf: Segoe UI Semilight Italic
>
> I have been floating this around to a few folks to gather initial feedback.
> Notably, Bram Stein from Adobe investigated the behavior of different
> browsers when presented with non-standard font-weight values:
>
>    "I’ve tested on all browsers I have access to (IE6+, Android 2.2+, iOS
> 4+, Firefox, Chrome, Opera, Safari, BlackBerry, etc.)
>     and all of them fall back to “normal” when they don’t recognize a font
> weight value (in either @font-face or by itself).
>      My test case is here: https://github.com/bramstein/font-weight-test"
>
>
> Should the restriction on font-weight be relaxed?
>  - all positive integers?
>  - all integers between 100 to 900?
>  - add 50 increments between 100 to 900?
>
> Best,
>
>
>