Re: [css-fonts] font-weight-adjust

> 
> On 19 Oct 2015, at 17:58, Jonathan Kew <jfkthame@gmail.com> wrote:
> 
> On 19/10/15 09:22, Florian Rivoal wrote:
>> With the same font-size, the apparent size of the text varies depending on the actual fonts used, and we have font-size-adjust to deal with that.
>> 
>> However, the same is true about font-weight, and we don't have a way to cope. Font-weights numbers are merely relative to each other within a font family. Just because two fonts both support the same numerical values for font-weight does not mean the stroke width and perceived thickness will be the same. Conversely, even if both font families have weights where they visually match each other, there is no guarantee that they will map these to the same numerical value.
>> 
>> Based on this, I suggest that a font-weight-adjust property, analogue to font-size-adjust property, would be a useful addition.
>> 
>> Sample use case, based on a real situation at encountered at Bloomberg:
>> 
>> You have a custom font, which you really like, and use for your body text. Its normal/400 font weight is somewhat thick (and its heavier weights are thicker). The fonts support a good chunk of unicode, but not all of it, so you have a fallback font to deal with the rest. The fallback isn't as nice, but but it's not practical to commission someone to make one that covers every language you need to support, and you've found a generic font that looks acceptable. However, this font (which also supports multiple weights) looks thinner than your favorite one at normal/400, so if you display chunks of text which rely on both fonts, such as CJK text (thin fallabck) with latin numerals (thick base font), it looks bad. The fallback font's 600 would be a better match for the base font's 400.
>> 
>> Using this:
>>   body {
>>     font-family: my-favorite-font, my-fallback;
>>     font-weight: 600;
>>   }
>> does not not solve it, since it also base the base font thicker, and the weight gap remains. So you'd like to say something like:
>>   body {
>>     font-family: my-favorite-font, my-fallback;
>> 
>>     font-weight-adjust: 400 to 600 / 600 to 800;
>> 
>>     /* imaginary syntax saying that for the fallback font,
>>     the UA should use the 600 (resp. 800) weight when 400
>>     (resp. 600)is specified.*/
>>   }
>>   strong {
>>     font-weight: 600; /* makes the base font 600, and the fallback 800 */
>>   }
>> 
>> Unlike font-size-adjust, I don't think we can use a multiplicative (or for that matter additive) factor, since font-weights, despite looking like numbers, are not something you can do arithmetic on, which is why I'm providing an explicit mapping.
>> 
>> Syntax aside (yeah, bikesheding ahead), does that make sense? If not, why not?
> 
> I can understand the desire, but am unsure how practical this would turn out to be.
> 
> What weight would be used for text that isn't covered by either my-favorite-font or my-fallback, where the browser has to go find some other fallback?

Fair enough, but isn't the problem identical for font-size-adjust?

> Would it perhaps be simpler to allow font-weight to take a list of values, corresponding to the list of font-family names? So then you'd say
> 
>  body {
>    font-family: my-favorite-font, my-fallback;
>    font-weight: 400, 600;
>  }
>  strong {
>    font-weight: 600, 800;
>  }
> or something like that. We'd still need to define what happens when system fallback kicks in (I assume we'd use either the first or the last in the list), or if the lengths of the lists don't match (if the font-weight list is longer, extra values are dropped; if it's shorter, behave like the system fallback case?)

This looks like it would cause more repetition in the stylesheet than the font-weight-adjust approach, but I suppose it would work.

But theoretically, we could have done the same for font-size-adjust and allowed multiple arguments to font-size. We didn't go that way, so I'm tempted to keep the same approach for both for consistency and learnability's sake.


> The same thing could apply to font-stretch, presumably:
> 
>  body {
>    font-family: my-favorite-font, my-fallback; /* where my-favorite is a rather condensed face */
>    font-stretch: normal, condensed;
>  }

Right. The problem seems analogous. I haven't run into it in practice, but in theory I see no reason it would be any different.

> HOWEVER, having said all that, I wonder if it'd be better to just use @font-face to construct a "virtual family" that handles the mappings you want:
> 
>  @font-face {
>    font-family: my-favorite-font;
>    font-weight: 400;
>    src: url(MyFavorite.woff), url(MyFallback-Semibold.woff);
>  }
>  @font-face {
>    font-family: my-favorite-font;
>    font-weight: 600;
>    src: url(MyFavoriteBold.woff), url(MyFallback-Extrabold.woff);
>  }
> 
> This allows you to collect whichever combinations of faces you like and map them to a given font-weight value for your virtual family. And adding unicode-range will allow you to optimize downloads and to manage more precisely what happens in areas of character coverage overlap.

That only works if the various font files you're linking to only support a single weight each. But if the normal and semibold versions of MyFallback are in the same font file, then you are back to square one. Even if we assume all authors are technically able to split a font file into multiple ones containing only 1 weight each (which is a stretch), not all font licenses allow you to do that.

So this is more of a partial workaround than a solution.

Allowing the multi-valued of font-weight in the @font-face, with the semantics being that you match on the first value, and adjust the nth font based on the nth value would probably work as well, but here again I am not sure why we'd handle font-weight differently from font-size.

 - Florian

Received on Monday, 19 October 2015 09:28:42 UTC