Re: [CSS21] last edition: pity

Maybe I'm missing something, but isn't all this font weight stuff kind
of meaningless given that the notion of "family" is
undefined/platform-specific, and the same set of fonts can and will be
one family on Mac and several families on Windows GDI?

That is, on Mac (and in Windows Presentation Foundation), you can have
a very large number of different weights in one family. As a practical
matter, in GDI you can have only two, a "regular" and a "bold." (Yes,
technically you could have more, but since about half of all GDI apps
would deal badly with the multi-weight family, including Microsoft
Office, nobody makes such fonts.)

In TrueType and OpenType, then, the *exact same fonts* thus end up
with data in them that divides them into more families for GDI
purposes, and fewer for OS X and "savvy" applications.

Cheers,

T

On Sun, May 10, 2009 at 10:55 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> 2009/5/7 Bert Bos <bert@w3.org>:
>> [...]
>>
>>> 4. 15 Fonts,
>>>     15.6 Font boldness : the 'font-weight' property:
>>>       'bolder' selects the next weight that is assigned to a font
>>> that is darker than the inherited one.
>>>     following sentence removed:
>>>       If there is no such weight, it simply results in the next
>>> darker numerical value (and the font remains unchanged), unless the
>>> inherited value was '900' in which case the resulting weight is also
>>> '900'.
>>>     [similar in 'lighter']
>>>     following paragraph added:
>>>       Note: A set of nested elements that mix 'bolder' and 'lighter'
>>> will give unpredictable results depending on the UA, OS, and font
>>> availability. This behavior will be more precisely defined in CSS3.
>>>
>>>     - changing _defined_ behaviour to _undefined_ is not an
>>> improvement. - css3 reference nonsence.
>>>       (imo: if someone tries to turn css2 specification into
>>>       'css3 todo list' - shoot, don't talk)
>>>     - the weight metric is independent from font[family].
>>>       as value of independent metric, 'bolder' SHOULD result next
>>> numerical value.
>>>       futher - as a hack for non-perfect world - it MAY (or MAY NOT)
>>>       yield to next available font's weight.
>>>       what was unclean here? why you killing primary objectives of
>>>       property/value, leaving only hack description?
>>
>> Imagine four nested elements, from outside to inside they have
>>
>>    font-weight: normal
>>    font-weight: bolder
>>    font-weight: bolder
>>    font-weight: lighter
>>
>> The old spec said the computed value of the innermost is "one of the
>> legal number values combined with one or more of the relative
>> values (bolder or lighter)." But does that mean
>>
>>    400 + bolder + bolder + lighter
>> or
>>    400 + bolder
>> or
>>    400 + 1 * lighter + 2 * bolder?
>>
>> That makes a difference. Assume a font with weights 400 (normal)
>> and 900 (extra bold). A UA that does the first will end up at 400,
>> while a UA that does the second will choose 900.
>
> Bolder is min(inherit + 100,900) and the computed value is a number:
> you solve the issue without complicating with the computed value. Bold
> computes to 700, normal and initial to 400. Lighter to max(inherit -
> 100,100).
>
>> The text about taking the next available weight or the next
>> numerical value if there is no next weight available dates from
>> the old CSS2 REC, and assumed that the computed value was a number.
>> But it didn't define what happened for elements with more than one
>> font family, so it's likely that taking the next numerical value
>> isn't actually a good idea.
>
> The font matching algorithm is in CSS3 Fonts, and
> 1) assumes a numerical weight
> 2) should work the same for bolder/ligther or explicit numbers
> As usual, first you find the computed values, then the used values
> (that require knowing the font metrics and availability) for
> rendering.
>
>> Maybe we will find a good solution before we progress CSS 2.1 to
>> Recommendation. That's currently issue 111[3]. But maybe we won't
>> and leave the algorithm undefined in CSS 2.1.
>>
>> [3] http://wiki.csswg.org/spec/css2.1#issue-111
>>
>>
>>
>> Bert
>> --
>>  Bert Bos                                ( W 3 C ) http://www.w3.org/
>>  http://www.w3.org/people/bos                               W3C/ERCIM
>>  bert@w3.org                             2004 Rt des Lucioles / BP 93
>>  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
>>
>>
>
> Giovanni

Received on Sunday, 10 May 2009 19:32:08 UTC