Bug 18311 – REGRESSION (r31620): Font variants (e.g. Helvetica Neue *Light*) don't render correctly

• Component: Text
• Status: RESOLVED FIXED

[Guillermo Esteves]

As of WebKit nightly r31623 on Mac OS 10.5, specifying, say, font-family: "HelveticaNeue-Light" or font-family: "HelveticaNeue-UltraLight" no longer renders the appropriate Helvetica Neue variant. They simply render as regular Helvetica Neue.

Screenshot available at http://img.skitch.com/20080404-1wh55gxup23k9q1p95spxbr4gj.jpg. On the left, you can see how it looks in nightly r31623, and on the right, how it looks in Safari 3.1

[Guillermo Esteves]

Created attachment 20332 [details]
Test document with paragraphs styled in a Helvetica Neue regular, light and ultra light.

The paragraphs in the document render correctly in Safari 3.1, but not in WebKit nightly r31623.

[Guillermo Esteves]

Created attachment 20333 [details]
Screenshot showing the difference between WebKit nightly r31623 (left) and Safari 3.1 (right).

[Matt Lilek]

Confirmed with the r31623 nightly and Safari 3.1 (5525.13).  While the previous nightly is 3 days old, my build from yesterday morning works fine, r31620 is really the only thing that is likely to have caused this.

<rdar://problem/5842980>

Created attachment 20335 [details]
Revert old behavior for full-name based matches

Not asking for a review yet because I think this may be problematic for families that
1. Have a regular weight whose full name is the family name and
2. Have more than one weight heavier than regular.

I really don't know how full name matches should behave and how they can be distinguished from family name matches when a family member's full name is the same as the family name.

Actually, the case that's broken by the proposed patch is the opposite, but I guess it was broken before r31620, so it will just be a reversion: you will not be able to get any lighter member of a family. One example is Copperplate, whose regular weight goes by the full name "Copperplate".

[Philippe Wittenbergh]

I believe the current (@ r31623) is correct. Per CSS 2.1:15 Fonts [1], the author specifies a font 'family' (e.g. Helvetica Neue). If you then want a specific face (e.g 'Helvetica Neue　Ultra-Light') within that family you use the font-weight property, in this case font-weight: 100.


[1] http://www.w3.org/TR/CSS21/fonts.html#font-family-prop

(In reply to comment #7)
> I believe the current (@ r31623) is correct. Per CSS 2.1:15 Fonts [1], the
> author specifies a font 'family' (e.g. Helvetica Neue). If you then want a
> specific face (e.g 'Helvetica Neue　Ultra-Light') within that family you
> use the font-weight property, in this case font-weight: 100.
> 
> 
> [1] http://www.w3.org/TR/CSS21/fonts.html#font-family-prop

It's true that letting fonts be selected by full name is non-standard behavior. My concern is that, like the reporter of this bug, there are authors and WebKit clients that expect this behavior. It might be good to maintain it, as long as it does not conflict with adhering to CSS2.1. As stated in comment #6, such conflicts can occur.

Created attachment 20385 [details]
Revert old behavior for full-name based matches but prefer match by family name

[Dave Hyatt]

Comment on attachment 20385 [details]
Revert old behavior for full-name based matches but prefer match by family name

r=me

Fixed in <http://trac.webkit.org/projects/webkit/changeset/31689>.