[css-fonts] Specifying changes to parameters for fallback fonts

[r12a]

After another session of fruitless wrestling with fonts, i thought i should make sure (a) i'm not missing something obvious, and (b) if not, ask whether we can improve CSS.

This time i was trying to get a particular look across Mac- and Windows-based browsers. On the Mac i like the look of Helvetica Neue with font-weight set to 300 at a font size of 16px. But i can't find anything to match that in Windows standard fonts – well, i could get reasonably close, but i'd need to be able to change the font weight and the font size for a font-family name specified as a fallback.

I've never understood why, in CSS, i can't say something like

p {
	font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif;
}

This is a much bigger problem in non-Latin scripts, where glyph dimensions can vary widely from font to font at the same font-size. For example, compare the same glyphs set to the exact same font-size in Mongolian Baiti and Noto Sans Mongolian:

It's not just mongolian, this is a constant problem in arabic, and many other scripts.

And by the way, i thought about web fonts, but i can't help thinking that you should be able to just use standard platform fonts if you want to. Note that that tweaking the size/weight of such fonts would be easier than finding fonts that look good and can be used for free to cover the up to 15 languages we have on the i18n site, but also we're often dealing with multiple languages on a given page for examples etc, which also ramps up the bandwidth when using webfonts.

What am i missing?

[duerst]

I fully agree with Richard. Actually, when I saw his comment, I said to myself: How obvious; why haven't I thought about this much earlier. Combining multiple scripts on a page always requires a lot of care with respect to size and also weight.
This functionality would actually also be very helpful for combining multiple fonts covering the same script. I have seen many cases where e.g. a monospace font for some program text didn't fit well with a proportional font used for the running text.
The only reason that I was able to think of for why we haven't thought of such a feature until now is that with low-resolution displays, such adjustments din't work very well. But with today's high-resolution screens, they are easily possible (and all the more desirable).

[tabatkins]

I agree with the problem statement, it's definitely valid. But there are some issues with the proposed solution:

• it makes font-size a list-valued property, which is a change we could make but still something new.
• BUT, the font-size ratio between fonts is probably constant across sizes, so having to write out a whole list of font-sizes every time you want to change the size of an element is a lot of wasted work (and makes the default HTML styles hostile; use your font in an <h2> or <small> and it gets messed up unless you specifically override it). You instead probably want a list-valued font-size-ratio property.
• BUT there's no way to line that up with the fallback font, which displays at some unknown size relative to the other fonts
• ALSO, font-size isn't the only thing you want to control; I've heard people want to coordinate weight or spacing between different fonts to get a consistent look.

The third point is probably unaddressable and we just need to leave it; that's just a fallback issue anyway and shouldn't get hit by well-designed content in normal circumstances. The rest, tho, suggest that the solution is higher than the property level and probably needs to be addressed either thru @font-face, or a new at-rule better suited for constructing a composite fallback-list with control over all the aspects at each point.

[litherum]

My biggest worry is about how this new syntax would interact with the existing font-weight and font-size properties. It seems very confusing to have two properties which may disagree.

I do agree that the current facilities for font fallback are lacking.

[r12a]

It seems we're all agreed on the problem statement, and that a solution needs to be found.

To be clear, I have no attachment at all to the syntax of the example solution i included in my original post (and btw @tabatkins the 300 and 500 were meant to be weights). I just want some way to indicate that various parameters should be different as you fall back to one of the named fonts.

I think that once you get to sans-serif all bets are off. It's just a question of specifying comparative parameters for the named font families in the fallback list.

I also suspect that the alternative parameters could be specified comparatively against the first item in the list of font-family fonts, or you could have some special rule which allows you to specify absolute font sizes (for example) and that then works out the ratios for you.

[upsuper]

I guess @font-face might be the right way to go. Probably a new descriptor e.g. font-size-ratio can be added into @font-face to address the font size problem.

I think weight difference is already resolvable via @font-face as you can specify full font name or postscript name in local().

This could be annoying for authors, though.

[r12a]

i gave some thought to @font-face yesterday, and concluded that actually it does the reverse to what we want. With @font-face you specify features and it selects a font on that basis, whereas for this we want to specify a font and then select features.

I suspected that maybe we need a new at-rule such as @fallback-font-sequence which allows you to specify a number of local or embedded fonts, associate them with each other, but then establish appropriate distinctions between their features. Then the @fallback-font-sequence could be given a name, which is used in the font-family property value. (?)

[litherum]

I was considering the idea of allowing font-weight and font-size to take a new value which would represent a normalized weight / size. Given that we're only concerned about preinstalled fonts here, the UA would likely have the information required to perform such a normalization. This would be much simpler than introducing a new at-rule.

[tabatkins]

Yeah, changing @font-face is the wrong way. What you described, @r12a, is what I was thinking of.

[frivoal]

No need to reach for mongolian, the same happens just fine in English. Baskerville as found on OS X vs Libre Baskerville, at the same font size and same weight, are very differently sized.

I've found myself wanting to use the OS X one as a default (it's got more open type features), and the libre one as a fallback, but the size being very different makes it tricky, and font-size-adjust cannot be used to adjust only some of the fallback fonts.

[frivoal]

Gérard said:

Florian,

Can you explain why you believe that 'font-size-adjust' can not be used to adjust (compensate) fallback fonts. I am not sure I understand what you are saying.

3.6 Relative sizing: the font-size-adjust property
https://www.w3.org/TR/css-fonts-3/#font-size-adjust-prop

In my mind, 'font-size-adjust' has been created specifically so that a fallback font (not available on a system) used size will be adjusted to match the first font of a list or to constrain all possible match of a font list to a certain size.

The glyphs will likely/possibly/probably not look the same but their relative size (aspect value) will be the same, must be the same:

http://test.csswg.org/suites/css-fonts-3_dev/nightly-unstable/html/font-size-adjust-003.htm

[frivoal]

Sorry, I was taking shortcuts and not explaining them well. font-size-adjust does indeed work, but it merely does the objectively thing, not the subjectively correct things.

The number you need to use for two fonts to feel the same size isn't always the same.

For instance, if you look at this example, preferably on a Mac, or on a computer that has a baskerville font with the same metrics installed:
http://jsbin.com/powokig/edit?html,css,output

For those who don't have the right fonts it looks like this

The first p has not font-size-adjust, and is obviously terrible.

The second one has font-size-adjust applied with the same value on both baskerville and libre baskerville. It's much better, but the two fonts, while close, don't feel quite the same. Libre Baskerville has comparatively shorter capitals, and due to the shape of the glyphs, the lower case letters feels every so slightly shorter as well, even if I am sure the metrics do match.

On the third p, I am applying a different font-size-adjust for baskerville and libre baskerville, which I think makes them subjectively more similar. I can do this here because I am actually specifying the fonts separately, but if I had been using fallback fonts, there would be no way for me to do that.

In this case, the difference is tiny, and nothing to loose sleep over, but the best result isn't the one you can achieve with font-size-adjust, and I suspect that as Richard mentioned, things get worse with internationalization.

[liamquin]

One difficulty here is that there is no way in CSS to say whose version of a font with a given name you want. In most cases all Baskerville fonts are the same - but what if there's one with pictures of dogs in it? Traditionally the font vendor would be named, e.g. Adobe Baskerville, and often these days include vendor names in the font name, but for example on my system I have 228 variants of Helvetica, many installed by different programs. The per-glyph fallback on a site that uses Helvetica means I start with a randomy-chosen Helvetica, then might get e.g. fi ligatures from a different one. I quite often see Web sites with the fi/fl/ff ligatures obviously in a different font, for example bolder when the font names didn't fit into the CSS 100-step boldness categories.

So there are several steps,
(1) choosing a base font family, which as Tab says needs some high-level work, e.g. to choose the first font family from a list, where that family has fonts to support roman and italic for a given character range along with specific other features, such as having a condensed variant, or having true small capitals;
(2) choosing a base font within that font family, without wandering off into some unrelated font that happens to have the same font name but came from a different vendor or foundry
(3) potentially modifying that chosen font, e.g. to simulate bold or oblique (ugh but there we go) or to condense or stretch it (some implementations do this if font-stretch is specified; others will only select a font that already exists with a corresponding font matrix (!) and at least one will simply leave blank gaps in the output where hte text shold be if font-stretch doesn't match)
(4) per-character and per-glyph fallback as needed, going back to step (2) and then repeating step (3).

Right now CSS fonts doesn't seem to give clear control over these steps, leading to some odd effects such as those you (Richard) see.

Selecting based on platform is not the right approach though - e.g. Richard left out Linux or Android, and desktop macs have different fonts perhaps than iphones, as do differing versions of Microsoft Windows. And many users have fonts that are from different platforms, whether from dual booting or (probably much more often) from installing applications that in turn installed fonts. The test should be for specific versions of fonts, or at the least specific foundries an capabilities (just like writing portable C or C++ tests for features, not for platform).

[duerst]

On 2016/05/29 11:11, Liam Quin wrote: Selecting based on platform is not the right approach though - e.g. Richard left out Linux or Android, and desktop macs have different fonts perhaps than iphones, as do differing versions of Microsoft Windows. And many users have fonts that are from different platforms, whether from dual booting or (probably much more often) from installing applications that in turn installed fonts. The test should be for specific versions of fonts, or at the least specific foundries an capabilities (just like writing portable C or C++ tests for features, not for platform).

I have only a vague recollection, but doesn't the X11 windowing system have information such as foundry,...? I don't think we can use that system as is, but maybe we get some additional hints out of it. Regards, Martin.

[litherum]

@liamquin In WebKit, we are interested in limiting font selection of local font faces to only the preinstalled fonts (disregarding any user-installed fonts). Originally, the purpose of this idea is to combat fingerprinting, but it also sounds like such a policy would also solve your item (2). However, we're still investigating this idea; we don't know yet if it will work.

[litherum]

It sounds like using something like @fallback-font-sequence would associate a small set of CSS properties with each item in the font family list, where it is obvious how to apply each property in that small set to individual glyphs rather than full elements.

In the related issue #450 (comment) we are investigating using this mechanism to better match fallback fonts to web fonts during the download of the web font. A small set of properties suggested are:
font-weight
font-size
letter-spacing
word-spacing
line-height

One thing we should consider is that, if these properties are all bundled up together into an at-rule, they don't cascade nicely. This means that if a web author wants to use an existing @fallback-font-sequence rule in a new context, but slightly modified, they would have to create a copy of the whole rule, including all the properties inside it.

[litherum]

In this model, we would also have to define the priority for the CSS properties inside the @fallback-font-sequence rule. Because there are no selectors, we would have to define what to do if the element already has those properties set.

• Perhaps the computed style of that property on the element is ignored for glyphs using fallback fonts.
• Or, perhaps we only allow relative values (like percentages) in these properties and resolve those percentages against the element's computed style. (This would require modifying the spec for letter-spacing because it currently only accepts a length.)

[controversial]

Is this something we'll ever get to see in CSS?

[css-meeting-bot]

The CSS Working Group just discussed Specifying changes to parameters for fallback fonts, and agreed to the following:

• RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors
• RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD

The full IRC log of that discussion

<gregwhitworth> Topic: Specifying changes to parameters for fallback fonts
<chrishtr> q+
<astearns> github: https://github.com//issues/126
<gregwhitworth> chris: the general principal is wanting to change things based on which font was actually used
<gregwhitworth> chris: so you set them conditionally, they expect a simple syntax. Much of this thread is to say that most simple solutions are not going to work
<astearns> ack chrishtr
<gregwhitworth> chrishtr: I wanted to point out a few things
<gregwhitworth> chrishtr: which syntax would be used
<gregwhitworth> chrishtr: main usecase that xiaochengh had in mind was automatically overriding when you have a fallback of a webfont you want to limit jumping of the webpage and add little to not difficulty to the author because it behaves automatically
<leaverou> q+
<gregwhitworth> chrishtr: the one alternative is to have a CSS property that has augmented syntax and I think that would end up being quite complex because it would need to repeat
<astearns> ack leaverou
<gregwhitworth> leaverou: there have been many proposals, they seem to revolve around changing the font-props
<gregwhitworth> leaverou: the syntax would get quite complicated
<gregwhitworth> leaverou: rather than change props let's add inline conditionals based on prior resolutions of inline conditionals
<gregwhitworth> leaverou: you can then branch however you want and it only gets as complicated as the author needs it to be
<gregwhitworth> leaverou: so you can end up with multiple font-families in a single element
<drott> q+
<gregwhitworth> leaverou: you don't want a different letter-spacing for every glyph for example
<gregwhitworth> leaverou: this gets future improvements for conditional syntax
<gregwhitworth> myles: one of the args against my proposal was unreadable and I think this may be more unreadable
<astearns> ack drott
<gregwhitworth> astearns: that would depend on the general usage but yes more flexibility usually adds complexity to parse
<gregwhitworth> drott: would you add a way to selector for the inline font?
<gregwhitworth> leaverou: no a keyword, such as accentColor
<gregwhitworth> leaverou: I can drop a link to the proposal
<leaverou> https://github.com//issues/126#issuecomment-775990597
<leaverou> s/accentColor/currentColor/
<xiaochengh> q+
<drott> q+
<gregwhitworth> astearns: I'm thinking this is a good thing to get too, but this more immediate need a descriptor rather than waiting for a solution to the conditional styling
<astearns> q?
<gregwhitworth> myles: in the last issue we were going to add one of these degrees of freedom to the descriptor
<gregwhitworth> myles: as a more concrete proposal should we try to add 4 additional descriptors to ensure alignement?
<chris> q?
<astearns> ack xiaochengh
<gregwhitworth> xiaochengh: the proposed syntax of this property is complicated and the implementation will be complicated too
<drott> q-
<astearns> ack fantasai
<gregwhitworth> xiaochengh: I'm not sure how to implement that in Chrome to be honest
<gregwhitworth> fantasai: I think going with the descriptor is a much better way than trying to embed this in font properties especially so many CSS calculations depend on those properties
<gregwhitworth> fantasai: properties are really weird to bind font-face to some value
<myles> q+
<gregwhitworth> fantasai: we can't just put it into the font-face rule, you'd want different styles to different elements, we're going to have derivitives of the same font-face with different overrides
<gregwhitworth> fantasai: it would be good to cascade in so you don't have to repeat them
<gregwhitworth> myles: so inheritance for at rules?
<leaverou> q+
<gregwhitworth> fantasai: cascading rules which is what counter style does
<gregwhitworth> fantasai: I support jonathan's proposal overall
<astearns> ack myles
<fantasai> jfkthame's proposal https://github.com//issues/126#issuecomment-764641927
<gregwhitworth> myles: one of the degrees of freedom is font-weight and that is a matching property
<gregwhitworth> myles: so if we want to have an override I'm not sure how that would work
<florian> q+
<cbiesinger> q+
<cbiesinger> hm
<cbiesinger> qq+
<gregwhitworth> myles: what that should mean is that that element shouldn't select the defined font-weight
<drott> q+
<gregwhitworth> chris: that shouldn't impact matching
<astearns> ack cbiesinger
<Zakim> cbiesinger, you wanted to react to myles
<chris> q?
<gregwhitworth> christian: could you solve that issue by having a font adjustment factor, so if the fallback is used you can multiply by something like 0.9
<cbiesinger> q-
<gregwhitworth> myles: so if you fallback to font-x use a factor of .8 or .9 for font-y
<gregwhitworth> myles: I think that's what chris was saying
<gregwhitworth> fantasai: would that work with variable fonts?
<gregwhitworth> myles: no it wouldn't work for var fonts
<gregwhitworth> fantasai: jonathan's solution has a mapping table
<gregwhitworth> florian: font-weight is the odd one here
<astearns> ack florian
<gregwhitworth> florian: they're not really numbers they're a way to match a font that happens to map to numbers
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<myles> q+
<gregwhitworth> florian: if we're dealing with variable fonts we need to map to ranges or series
<gregwhitworth> florian: the others are actual measurements, this one is weird
<gregwhitworth> leaverou: I want to say we're discuss two orthogonal issues and one is trying to provide a better fallback and one trying to improve styling for ones that were selected for fallback
<drott> q-
<gregwhitworth> leaverou: there are usecases that are local fonts eg: Mac vs Windows fonts
<gregwhitworth> myles: the folks we've talked with are fine with font-face being used
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<TabAtkins> ScribeNick: TabAtkins
<TabAtkins> myles: There are these props we're interested in
<TabAtkins> myles: weight, size, letter-spacing, word-spacing, line-height
<TabAtkins> myles: line-height might be taken care of by ascent/descent-override
<TabAtkins> myles: letter-sacping resolved in last issue
<TabAtkins> myles: font-weight sounds hard, need more time
<TabAtkins> myles: but font-size and word-spacing, maybe we could make progress
<TabAtkins> jfkthame: font-stretch?
<TabAtkins> myles: could be. would you like it to be?
<TabAtkins> chris: yeah, condensedness should be in the list
<florian> q+
<TabAtkins> astearns: Wondering if we should have a general reoslution to solve these things as @font-face descriptors, and start getting spec text for this
<leaverou> q-
<chrishtr> Agreed on font-face resolution being a good next step.
<chrishtr> And then discuss types of overrides.
<TabAtkins> astearns: For previous issue, for the simpler things here, and then ahve separate issues for each type of override
<TabAtkins> astearns: This is alread a giant issue that tends to spin out into overlapping convos
<chris> Yeah that sounds like a plan
<astearns> q?
<TabAtkins> florian: A discussion over the break: instead of specifying the amount you want to adjust the font, specify the target amount
<TabAtkins> florian: UA could adjust automatically, but could be flexible with variable fonts, etc
<TabAtkins> florian: Or choose different fallbacks with better metrics
<fantasai> TabAtkins: That might work for some things, but I can't see how it would work for advance
<TabAtkins> myles: It'd be an overall tracking value, like "make the average character width X sized"
<TabAtkins> jfkthame: Too many questions there, how to average?
<TabAtkins> florian: Not harder than just using the adjustment
<fantasai> TabAtkins: Disagree
<fantasai> TabAtkins: Current proposal only adjust the fallbacks.
<fantasai> TabAtkins: Take the good font, then load fallback and tweak it until to works
<fantasai> s/works/works the way you want
<TabAtkins> myles: This is why I opened an issue for font-size-adjust:auto
<TabAtkins> myles: Right now author needs to guess
<fantasai> TabAtkins: At least you can guess and check for font-size easily, but see your point in general
<TabAtkins> myles: So suggested we have an auto for that
<astearns> ack fantasai
<astearns> ack florian
<TabAtkins> fantasai: There was discussion about reoslution
<TabAtkins> fantasai: proposed resolution is to address these use-case with descriptors
<TabAtkins> fantasai: Don't think we can be more specific atm
<TabAtkins> fantasai: I know Chrome wants to address the advance-override case sooner rather than later, so we should make progress on making that concrete
<TabAtkins> astearns: So resolve the general descriptor, and specifically add advance-override
<TabAtkins> fantasai: in Fonts 5?
<TabAtkins> myles: yeah
<TabAtkins> astearns: objections?
<TabAtkins> jfkthame: Not quite sure we know what advance-override means yet - details tbd?
<TabAtkins> astearns: Yes, we resolve to add it, can spin out issues to nail down details.
<TabAtkins> RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors
<TabAtkins> RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD

[r12a]

As an aside, I'm not really convinced it's worthwhile to try and refine this stuff to such a degree. Fallbacks are just that: fallbacks. They may or may not even be available on a given user's system; you might end up with some other default/generic anyway. They aren't expected to render identically to the target webfont, no matter how many knobs we provide to tweak them.

What follows may be a slightly philosophical point.

I'm glad to see how the ideas here can also be applied to fallbacks related to web fonts, etc. I just didn't want to lose sight of my original problem, which was: There are very few Mongolian fonts, but pages on Windows will have guaranteed access to Mongolian Baiti, and pages on OS X will not have access to Baiti but will have access to Noto Sans Mongolian. The problem being that the metrics of these fonts on display are very different. So i just wanted a simple way to be able to say: If the browser is using Baiti, use these additional settings for font size, density, etc; if the browser is using Noto, use these other settings. So it's a use case that doesn't attempt to make the font look alike, but does attempt to produce something that takes up the same amount of space and works well for readability. In this sense, this is a slightly different kind of 'fallback' behaviour in that you actually pretty much know which font is likely to be used in which case. Solving that issue will be very useful for working with non-Latin fonts.

[jpamental]

@r12a I'm completely in agreement with you!

My use case is essentially the same: I want to make sure that the type fits in the same space to avoid reflow or massive amounts of repaint. Having it look the same (mimicking x-height for example) is not really important to me. I just want things to stay in the same place so if no web fonts show up, the integrity of the design/layout is maintained. And if they do eventually show up, nothing moves around.

In this way, both circumstances benefit!

[litherum]

A solution that utilizes @font-face descriptors isn't just for web fonts - @font-face blocks can use src: local(...) to represent local fonts, too.

[litherum]

Alright, I've broken up this issue into individual pieces, as per the discussion at the F2F:

• font-weight (low priority, since we already have a solution for non-variable fonts)
• font-stretch (low priority, since we already have a solution for non-variable fonts)
• font-size (low priority, since we already have font-size-adjust)
• word-spacing
• I think letter-spacing is already covered by [css-fonts] Reduce layout shift via @font-face descriptor(s) overriding inline spacing  #5533
• I think line-height is probably covered by ascent-override, descent-override, and line-gap-override

[litherum]

Now that I think about it, I suppose can probably close this issue in favor of those other, more narrow issues

[r12a]

Wait a sec – the use cases in your new issues @litherum seem to completely ignore the original use case for this issue, which i repeated a couple of comments back. It's not only about tweaking the look of fallback fonts while web fonts are loading; it's also about setting different sizes, weights, etc depending on which system font the browser is going to use.

I read the transcript from the session yesterday, but i can't say i understand what the actual proposal is other than that it will be done via @font-face descriptors.

@literum could you, or somebody, give an example of what the syntax may look like (approximately/grosso modo) if one wants to resolve, say, the Mongolian issue i described above?

[LeaVerou]

@r12a Not sure how well that was minuted but I made that exact point in the call and was told that system fonts should also be declared via an @font-face rule (and local()).

[jfkthame]

@litherum With regard to:

• font-size (low priority, since we already have font-size-adjust)

I'm not sure font-size-adjust really covers this, especially for non-Latin fonts where the concept of ex-height may not be at all well defined, and there's a good chance that whatever data may be in fonts won't be appropriate to harmonize across families.

So to take @r12a's example of Mongolian, I imagine an author might want to write something like (using a hypothetical font-size-override descriptor):

@font-face {
    font-family: AdjustedBaiti;
    src: local("MongolianBaiti");
    font-size-override: 125%;
}
@font-face {
    font-family: AdjustedNotoMongolian;
    src: local("NotoSansMongolian");
    font-size-override: 75%;
}

body { font-family: AdjustedBaiti, AdjustedMongolian, serif; }

and this would use Baiti if available, enlarged to 125% of the computed font-size; or else Noto, reduced to 75%; or if neither of these are present, you'd end up with whatever serif maps to or whatever fallback finds.

font-size-adjust doesn't feel like the right tool for this, given its very specific (and Latin-oriented) definition. I suppose in theory if it were a descriptor, it would be possible to determine a font-size-adjust value for each @font-face rule that would yield the desired size relationship, but it feels really awkward.

(Maybe a solution would be an ex-height descriptor, so that you could specify an arbitrary value for a given face, to get control of what font-size-adjust will do for it even if it's a non-Latin script with no inherent "ex-height" and where the value in the font resource itself may be meaningless. Still feels like a cumbersome way to go about things, though.)

[liamquin]

On Wed, 2021-02-10 at 11:01 -0800, jfkthame wrote: [...]

   body { font-family: AdjustedBaiti, AdjustedMongolian, serif; } and this would use Baiti if available, enlarged to 125% of the computed `font-size`; or else Noto, reduced to 75%; or if neither of these are present, you'd end up with whatever `serif` maps to or whatever fallback finds.

More precisely, that would be done on a per-character basis, so if there's a character in the 2nd but not the 1st font, and the rest are available in the 1st, you get a mix. I'm not sure that anything could be done better, except that you may very well want (or need) different fallback fonts depeing on the font chosen. There's also no way with font-face to say, if Helvetica was chosen for the regular font in this element, use Helvetica-oblique as the italic font, and if Helevetica-Oblique is not available, use serif as the font for p, not Helvetica at all. So i think i'd prefer to see a @font-family() or @font-set() that can have a use-when: all-available property. That way multilingual documents have a much better chance of working. I don't think that affects Richard's original use case, though. Part of what's going on here is the need to control the relationship between selecting a font and modifying text properties -- font-size, whether small caps, whether italic, colour, letter-spacing, maybe even font-stretch -- based on the selection.

…

-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

[svgeesus]

I'm not sure font-size-adjust really covers this, especially for non-Latin fonts where the concept of ex-height may not be at all well defined, and there's a good chance that whatever data may be in fonts won't be appropriate to harmonize across families.

I agree. font-size-adjust was designed (in, like, 1997, by Todd Fahrner) for Latin, and also works with Cyrillic and Greek scripts. If you want to harmonize two fonts sizes for Arabic, or Hebrew, or Devanagari, then (best case) it has no benefit and (worst case) it adds irrelevant, random re-scaling which may make things worse..

[svgeesus]

@r12a wrote:

the use cases in your new issues @litherum seem to completely ignore the original use case for this issue, which i repeated a couple of comments back. It's not only about tweaking the look of fallback fonts while web fonts are loading; it's also about setting different sizes, weights, etc depending on which system font the browser is going to use.

I think I captured this in this comment on the new font-size issue

If that is correct I can add that third use case to the other new issues spawned from this one.

[r12a]

Thanks, @svgeesus. I think i'd have written:

• Being able to tweak the look of any font in the font stack where the fonts in the stack have very different visual sizes or other metrics.

Removing the mention of fallback, for me, makes the rules less rigid about which font(s) in the stack get the adjustment, and allows you to move fonts around in the stack as you wish, later. I think we're looking for a scenario here where the adjustments are applied to a font to fit a context, rather than to match the first font in the stack (though that's a subtle difference). It also makes the example that @jfkthame provided at #126 (comment) work.

I removed 'for the script being rendered' because, on reflection, this adjustment could be just as useful for, say, a situation where you want to specify an Arabic font with no Latin glyphs and a Latin font such that they look as if they match in a single piece of Arabic text containing Latin acronyms or names. This is a frequent issue for me in Arabic (naskh and nastaliq styles), as well as for other scripts.

[litherum]

@r12a

@litherum could you, or somebody, give an example of what the syntax may look like

Given your example:

p {
	font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif;
}

It would look something like this:

@font-face {
    font-family: 'macfontname';
    font-weight: 300;
    font-size-override: 100%; /* not actually necessary, but included for explicitness */
    src: local("macfontname-300weight");
}

@font-face {
    font-family: 'windowsfontname';
    font-weight: 300; /* this is intentionally *not* "500" */
    font-size-override: 112.5%;
    src: local("windowsfontname-500weight"); /* *this* is where you specify you want weight 500 to be rendered */
}

...

p {
	font: 300 16px 'macfontname', 'windowsfontname', sans-serif;
}

[r12a]

Thanks, @litherum. I thought that the existing descriptors in @font-face such as font-weight are for matching/finding fonts, rather than modifying them. Could easily be that i'm wrong? I would have expected to see something similar to font-size-override, let's call it font-weight-override to actually apply modifications to the incoming font. (So you might have both font-weight and font-weight-override in the list of descriptors.)

The value for font-weight-override would presumably be a numeric offset, such as +100, or -200, or so on? Or maybe (?) something like bolder, which i think is currently not allowed for @font-face descriptors.

With that arrangement i think you wouldn't need to add stuff to the local() argument, which i think is cleaner - you'd just have the font name, as usual. In addition, it seems odd to modify the font weight in local("windowsfontname-500weight") but to modify the font size in font-size-override.

does that make sense?

So i guess i was expecting something like this:

@font-face {
    font-family: 'harmonisedMacfontname';
    src: local("macfontname");
    font-weight: 300;
    font-size-override: 100%;
    font-weight-override: +100 /* not necessarily needed, but could perhaps be useful */
}

@font-face {
    font-family: 'harmonisedWindowsfontname';
    src: local("windowsfontname"); 
    font-weight: 300;
    font-size-override: 112.5%;
    font-weight-override: -100;  /* of course, only needed if the font comparison merits it */
}

...

p {
	font: 300 16px 'macfontname', 'windowsfontname', sans-serif;
}

[svgeesus]

I thought that the existing descriptors in @font-face such as font-weight are for matching/finding fonts, rather than modifying them.

These descriptors define the characteristics of a font face and are used in the process of matching styles to specific faces.

So yes, the descriptors are used for matching against - the properties (requests for styling) are matched against the descriptors (descriptions of the fonts that are available).

The descriptors typically contain values extracted from the font; but they need not do so. And the font is not automatically opened and checked against the descriptors, if that is what you were thinking.

So for example the font family name is usually the same as what the font contains - but it need not be. It is common to make the name shorter for example. And it can be something different entirely.

And the font weight is typically what the font says it is, but (for non-variable fonts) could be set to anything. I could point to a heavy, ultrabold font which is weight 800 and have the descriptor say it is weight 200, for example (not very useful, but possible). More usefully I could decide that this particular font looks heavier than it claims to be, so I could set the font-weight descriptor to 830 instead.

An issue is that, while massaging (or lying about, as some prefer to say) non-variable fonts is easy, it becomes harder for variable fonts because we are trusting the font more. A variable font with a weight axis may cover, say the range 200 to 500. I can massage this by using a font-weight descriptor of 280 500, meaning I don't want it to match for weights below 280; but if it does match, there is no way for me to say "given a weight n, ask this font for weight a + n * b.

[svgeesus]

Or maybe (?) something like bolder, which i think is currently not allowed for @font-face descriptors.

Correct, it is not: auto | <font-weight-absolute> <font-weight-absolute>?

because bolder would not be describing anything (bolder than what?) so is unsuitable for a descriptor.

On the other hand bolder is fine as a property value (make this bolder than the parent, please)

[LeaVerou]

One issue with doing this all via descriptors even for local fonts is that @font-face is for single faces (let's leave variable fonts out for now). So, if I want to declare e.g. that if Helvetica Neue is used, I want tighter letter-spacing, I would need to declare dozens of rules, one for each Helvetica Neue face. Even just scoping it to Helvetica Neue Bold still requires several rules, especially if there are condensed and expanded faces available etc.

Also, the way matching is done in the font-family property is not the same as in the local() function. The latter requires the locally installed name, which can vary a lot, even for the same font.

[jfkthame]

This is why I tried to suggest in #126 (comment) that the place for these descriptors is in a new @-rule that addresses the family rather than the individual face. This would provide a customizable mapping from the "nominal" property values as used in the CSS to adjusted values that should be used with the specific family.

[jpamental]

The only way I think it will be really usable for the case that I was describing is on the selector level: meaning a specific font and usage needs this 'fallback correction' for one or more fallback font. I don't think this is helpful enough on a font family as you would need different corrections for different weights of a font (or variant in the case of italics), and applying the same correction for all uses of a single font across all selectors doesn't help either if you are using a bold weight with negative letter-spacing in a header and normal spacing with adjustments for fallbacks in body copy.

[svgeesus]

Related: Font styles & font fallback