[webkit-reviews] review requested: [Bug 12530] [CSS2] Support the font-stretch property : [Attachment 12865] patch v 1.0

bugzilla-request-daemon at macosforge.org bugzilla-request-daemon at macosforge.org
Thu Feb 1 17:51:24 PST 2007

Nicholas Shanks <contact at nickshanks.com> has asked  for review:
Bug 12530: [CSS2] Support the font-stretch property

Attachment 12865: patch v 1.0

------- Additional Comments from Nicholas Shanks <contact at nickshanks.com>
This patch has two known bugs:
1) The font-stretch property doesn't appear in the Web Inspector palette. I
don't know where to fix this.
2) A font which has only Regular and Condensed faces (such as those used in the
layout test) will fail when it encounters code such as:

<p style="font-stretch: wider"> foo <span style="font-stretch: narrower"> bar
</span> baz </p>

The "bar" in the above is supposed to be Condensed, but at present is not. This
bug is encountered when the FontDescription asks for a stretch that cannot be
met and the 'narrower' value is calculated from this unmet stretch, and not the
actually used stretch. I am unable to come up with a means of telling the
FontDescription the bad news. I tried adding member vars to FontPlatformData
but couldn't find a solution.
(hixie and dbaron confirmed that my expected behaviour is what should ocour,
and the present be)

The code that selects "a closer weight regardless of traits" is needed for
situations where say you want a Extended Bold Italic but only Regular, Bold and
Italic are available. In this case, The Bold will be chosen, oblique
synthesised and stretch ignored. It could have been dealt with in the Traits
hierarchy below with some more complicated code, but since I intend to remove
the NSBoldFontTrait from that with my font-weight patch anyway, saw no need to
add code here and take it away again tomorrow. The more complicated code (that
was actually a bit buggy with Italic 600 weight) can be seen in my first patch
on bug #6484.

Also, requests for condensed and extended traits are ignored when finding a
first match. Without this, requests with those traits could fail to match even
the fall-back fonts, and thus lock up the browser.

There is currently a regression somewhere in the tree that causes Lightest
weights to be selected instead of Regular. The code touched by this patch is
never reached and so this problem is not fixed.
Until I fix that regression (with the aforementioned font-weight patch) you'll
need to disable the fonts American Typewriter Light and Helvetica Neue
Light/UltraLight to get the test to pass. I could have provided a different
expected result but then people who don't have these fonts won't pass instead,
and I would have to update the results along with the font-weight patch.

More information about the webkit-reviews mailing list