Re: bolder/lighter defintion

On Tue, Mar 23, 2010 at 4:23 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 05/18/2009 07:00 AM, John Daggett wrote:
>>
>> 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.
>>
>> This is my proposed wording:
>>
>>>
>>> Values of 'bolder' and 'lighter' indicate values relative to the weight
>>> of the parent element.  Based on the inherited weight value, the weight
>>> used is calculated using the chart below.  Child elements inherit the
>>> calculated weight, not a value of 'bolder' or 'lighter'.
>>>
>>>   Inherited value   bolder  lighter
>>>   100               400     100
>>>   200               400     100
>>>   300               400     100
>>>   400               700     100
>>>   500               700     100
>>>   600               900     400
>>>   700               900     400
>>>   800               900     700
>>>   900               900     700
>>>
>>> The table above is equivalent to selecting the next relative bolder or
>>> lighter face, given a font family containing normal and bold faces along
>>> with a thin and a heavy face. Authors who desire finer control over the
>>> exact weight values used for a given element should use numerical values
>>> instead of relative weights.
>>>
>>
>> For situations where only two weights exist, normal and bold, this will
>> lead to the same behavior as the previous definitions, with the exception
>> of the behavior in complicated nested elements that we've discussed
>> before.  It results in a computed weight that is a valid weight.  For
>> fonts with several weights it separates those into clearly distinct
>> levels, ones with a perceivable difference in weight (e.g. jumping from
>> normal to medium isn't as clear as normal to bold).
>
> The problem with this proposal is that it doesn't roundtrip very well.
> If I start at 300 and go bolder, then lighter, I don't get back to my
> start: I get 100 instead of 300. The same is true of many other start
> points. It might not make a difference in a font with few weights,
> but in a font with all weights available, it's likely to be noticeable.
>
> There are some hole-filling rules in the font-weight section of CSS2.1:
>
>  # If there are fewer then 9 weights in the family, the default
>  # algorithm for filling the "holes" is as follows. If '500' is
>  # unassigned, it will be assigned the same font as '400'. If any
>  # of the values '600', '700', '800' or '900' remains unassigned,
>  # they are assigned to the same face as the next darker assigned
>  # keyword, if any, or the next lighter one otherwise. If any of
>  # '300', '200' or '100' remains unassigned, it is assigned to
>  # the next lighter assigned keyword, if any, or the next darker
>  # otherwise.
>
> Here's an alternate table that similarly guarantees significant
> bolder/lighter jumps, but also preserves round-tripping better by
> taking advantage of the hole-filling rules and their biases:
>
>  |    Inherited value   bolder  lighter
>  |    100               400     100
>  |    200               400     100
>  |    300               500     100
>  |    400               600     200
>  |    500               700     300
>  |    600               800     400
>  |    700               900     500
>  |    800               900     600
>  |    900               900     700
>
> Is there a reason why you had to clamp to 100/400/700/900 in your
> table instead of doing something like this?
>
> ~fantasai

I think I mentioned before, one limitation of this table is that it
only handles values in even 100s, when real-world fonts sometimes use
in-between numbers. Notably (but not only) some fonts from Adobe.

Cheers,

T

-- 
"The rat's perturbed; it must sense nanobots! Code grey! We have a
Helvetica scenario!" — http://xkcd.com/683/

Received on Wednesday, 24 March 2010 02:12:41 UTC