RE: bolder/lighter defintion

John,
  When I circulated you proposal within Adobe (after having replied to you, without looking carefully enough at the table; I understand your response to me.) I got the following problematic example:

The basic problem is the difference between "lighter" and "bolder" (which CSS is apparently trying to specify) and "lightest" and "boldest" (which is what John's table will produce).

Imagine a family with weights of 175, 300, 400, 550, 650 & 800. (This is the sort of value set that GDI drives font vendors to in a multi-weight family.) Presuming the algorithm will look for the value closest to the output of John's table, the 300 and 550 will never be selected. That's contrary to the goal of incrementing (or decrementing) through the available weights.

Apparently GDI's behavior limits what values can be specified as font weights. For example, 100 does not work at all. This has lead to using weights in the font (as above) that are not multiples of 100. I think that Thomas Phinney's message was telling you this, but without having a particular example. The current weight table algorithm in CSS 2.1 will not work with such a font. It seems to assume weights are always multiples of 100.

I do not think it is a big deal to map the above values to weights in the 100-900 range. In the above case, using the nearest greater multiple of 100 would give 200(175), 300, 400, 600(550), 700(650), 800. Then the existing rules in CSS 2.1 section 15.6 for filling the holes would make 100 be the same as 200 and 900 be the same as 800. This does not solve the issue of the "bolder/lighter" computed value skipping some weights; it only gives a way of making the above font work in the font matching algorithm. (Note that there were no weight collisions (two weights getting the same table entry) in the above font using the nearest greater multiple of 100, but one could see that such collisions might actually happen if weights are less than 100 units apart.)

I think I still support your simplification for the relative value keywords, but it is disturbing that relative values will not work nicely with fonts that have 5 or more weights.

> -----Original Message-----
> From: John Daggett [mailto:jdaggett@mozilla.com]
> Sent: Monday, May 18, 2009 5:57 PM
> To: Stephen Zilles
> Cc: www-style
> Subject: Re: bolder/lighter defintion
> 
> >> The solution to this problem I proposed at the last F2F was to replace
> >> the bolder/lighter definitions with a simple mapping that's independent
> >> of the font family in use.  It's equivalent to running the existing font
> >> matching algorithm using a family with weights 100, 400, 700 and 900.
> 
> [SZ] This mapping avoids having the computed value depend on the font(s)
> [SZ] in use at the point where the relative value is used to change the
> font
> [SZ] weight. It is equivalent to always choosing the computed value to be
> the
> [SZ] next higher or lower weight in an artificial font family with weights
> [SZ] 100, 400, 700 and 900. The chosen computed weight is then used in the
> [SZ] font matching algorithm with the fonts actually in use to find the
> [SZ] weight that best matches the computed weight as already defined in the
> [SZ] specification. For most fonts, this will produce a font weight that
> most
> [SZ] often matches the authors expectations and the rules for resolving a
> [SZ] sequence of "bolder"s and "lighter"s are simple to understand.
> 
> I think we're saying the same thing.  But "it is equivalent to always
> choosing the computed value to be the next higher or lower weight in an
> artificial font family..." is not quite right.  For example, if the
> parent element has font-weight set to 600 and the child element is
> bolder, the "next higher" weight face is actually 900, since 600 maps to
> 700 in this family.  The inherited weight is first mapped to a weight
> that exists in the family, *then* the next higher weight is chosen.
> 
> Here's a visual representation of this:
> 
> http://people.mozilla.org/~jdaggett/bolderlightermappings.png

> 
> John

Received on Tuesday, 19 May 2009 02:16:49 UTC