Re: [css3-fonts] Nested 'bolder' and 'lighter' question

That seems very reasonable, and predictable.

Is there any reason why a UA should employ a "fake bold" when the bold  
is not available? In the old days of bitmapped fonts, that would be  
done by sliding a duplicate of each glyph to the right one pixel, and  
adjusting its used width to match. Nowadays it can be done by adding  
stokes to each glyph, and adjusting its used width to match. This  
would work for bolder fonts that you don't have, but not for lighter  
fonts that you don't have.

Also, if the first font on the list is available, but without the  
correct weight, could it look to the next font on the list for the  
proper weight, and use that as a fallback?



On Aug 29, 2008, at 8:48 AM, Bert Bos wrote:

>
> L. David Baron wrote:
>
>> 15.6 contains some contradictory statements as a result of previous
>> edits [1] which were themselves needed to resolve existing
>> contradictions.  See
>> http://csswg.inkedblade.net/spec/css2.1#issue-48 (and note that what
>> we're discussing is issue 49).
>
> Another way to solve issue 48 may be to re-use the concept of "first  
> available font" that we introduced to define the value of 'ex'.
>
> Concretely: remove no text from 15.6, but add this bullet point  
> before the two that define 'bolder' and 'lighter'. It says to only  
> look at the first family:
>
>  * Determine the font weight mappings of all fonts (of any style, size
>    or variant) in the first family in 'font-family' that has any fonts
>    available. Compute the used value of 'font-weight' using this set  
> of
>    fonts, as follows:
>
> The existing bullets could remain unchanged or cleaned up to avoid  
> some confusion and ambiguities, as follows:
>
>  * 'bolder' selects the next weight that is assigned to a font that is
>    darker than the *parent's weight* [was: inherited one]. If there is
>    no such weight, it simply results in the next darker numerical  
> value
>    [remove: (and the font remains unchanged)], unless the inherited
>    value was '900' in which case the resulting weight is also '900'.
>
>  * 'lighter' is similar, but works in the opposite direction: it
>    selects the next lighter keyword with a different font from the
>    *parent's weight* [was: inherited one], unless there is no such
>    font, in which case it selects the next lighter numerical value
>    [remove: (and keeps the font unchanged)].
>
>
>
> With this addition the original algorithm (next available font or  
> +100) is well-defined again and the outcome of Fantasai's puzzle is  
> as Sylvaing said:
>
> b -> 700 (because a bolder font is available and it has weight 700)
> c -> 800 (because no bolder font is available, so we just add 100)
> d -> 700 (because a lighter font than 800 is available, viz., 700)
>
> and thus d is bold.
>
> It will satisfy some people's intuition ("in an ideal font d would  
> be bolder than a") and fail others ("in an ideal font, d would be  
> lighter than c"). You can't win...
>
>
>
> For issue 49, this means that the computed value of 'font-weight' is  
> neither a sequence nor a count, it is simply an absolute weight  
> (100..900), *but* it cannot be computed without knowing the  
> available fonts.
>
> That shouldn't be a problem in most cases, except when the font is  
> not yet downloaded when you compute property values. In that case  
> you must either wait until the font is downloaded and installed, or  
> continue assuming the font does not exist and recompute properties  
> if it later turns out that the font downloaded and installed fine.
>
> The same is true for any calculations that involve 'ex', so it's  
> nothing new.
>
>
>
> 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
>

Received on Friday, 29 August 2008 16:44:15 UTC