[css-fonts-5] Add glyph scaling override descriptor to @font-face

[fantasai]

In #5983 (comment) @jfkthame wrote:

I think there should be a separate font-size-override that can apply a scale factor to the used font size; I suspect this would often be the better tool to use.

Using a scaling factor to make adjustments for font fallback would avoid some of the more problematic aspects of advance-override (breaking cursive/complex scripts, breaking typographic rhythm by adding uneven spacing, breaking alignment at the edges of paragraphs).

It also provides a long-needed feature--optically matching fonts when mixing font faces--by allowing per-font scaling adjustments at the author's discretion. font-size-adjust does this for certain bicameral scripts by using the ex-height metric, but that doesn't work more generally across writing systems as noted in #4540 .

The proposal would be to add a descriptor taking a percentage and effectively functions the same as font-size-adjust for a given scale factor. Details to consider [suggestions in brackets to match font-size-adjust]:

• Effect on em units? [No effect on em.]
• Effect on ch/ic/ex units? [These are supposed to match glyph metrics, so are affected.]
• Effect on baseline table? [Scales the table.]
• Effect on ascent/descent metrics? [Should scale them also.]
• Effect on ascent-override/descent-override/etc.? [Scales with the scale factor.]
• Allow separate vertical/horizontal scale factors? [No idea. We can start with one and see if independent axes are needed.]

[fantasai]

Possible names: glyph-scale-factor, font-size-adjust, glyph-size-adjust, size-adjust.

[jfkthame]

Thanks for filing this! Mostly agree with the suggested details above, with one doubt:

* Effect on `ascent-override`/`descent-override`/etc.? [Scales with the scale factor.]

Not sure about this one. ascent-override etc are not derived from the size of the glyphs, they're provided so that the author can override the metrics coming from the font and establish known line-spacing metrics that are not dependent on the specific font:

the corresponding metric value is resolved as the given percentage multiplied by the used font size

(from css-fonts 4.11. Default font metrics overriding).

In my understanding, the scale factor proposed here is not altering the "used font size". Given the simplest case of content like:

<div style="font: 20px MyFont">foo bar

the specified, computed and used font sizes are all 20px. If MyFont has both metrics overrides and a glyph scaling descriptor applied:

@font-face {
    font-family: MyFont;
    src: local("Arial");
    glyph-scale-factor: 90%;
    ascent-override: 90%;
    descent-override: 30%;
}

the resulting ascent and descent metrics, used to compute the line box, remain 18px (90% * 20px) and 6px (30% * 20px) respectively. The glyph scaling just applies to the glyph outlines themselves (so this rule is "shrinking" Arial by 10%) and to metrics that are based on their measurements (the glyph advances, units like ch and ex, the default line metrics like ascent/descent that are derived from the font) but it does not affect anything based on font-size, which is unchanged.

One result of this -- which I think is correct -- is that glyph-scale-factor (or whatever it's called) will normally affect ch, ex, etc for the font to which it is applied. But in the event that the browser cannot determine these values from the font, and falls back to default heuristics as provided in CSS Units & Values:

In the cases where it is impossible or impractical to determine the measure of the “0” glyph, it must be assumed to be 0.5em wide by 1em tall. Thus, the ch unit falls back to 0.5em in the general case, and to 1em when it would be typeset upright (i.e. writing-mode is vertical-rl or vertical-lr and text-orientation is upright).

the resulting unit is not affected by the scale factor.

[jfkthame]

One other question is how this interacts with optical sizing, for fonts that offer an opsz variation axis.

I think the right answer is that it does affect the automatic application of opsz, but I haven't thought this through in detail; perhaps there are implementation considerations that will make that trickier.

[xiaochengh]

I generally agree with @jfkthame.

One subtle issue is that, what exactly is the value being overridden? It should not be the font-size property value, neither computed nor used, since they work at different levels and should better not have extra dependency.

It feels more like hacking the font matching algorithm that, when trying to find a face with font size, say, 24px, we instead return a face of a different font size, and use it for text layout as if it were 24px.

Is there a nice way to specify it?

[drott]

One subtle issue is that, what exactly is the value being overridden? It should not be the font-size property value, neither computed nor used, since they work at different levels and should better not have extra dependency.

My understanding is the intention is not to use a fully down- or upscaled font internally as that would affect the line height. As @jfkthame explains, ascent / descent would still be computed from font-size:, which I think makes sense (otherwise what's the difference to using a different font-size: to start with? So perhaps it can be described from an implementation perspective as splitting the internal font object used for retrieving metrics for line height (ascent, descent) in layout from the one that we use to actually perform inline layout with, that we shape with, and that we shape with. Or perhaps more simply put: Keep line height, ascent, descent, baseline computations based on font-size: and original metrics at font-size: (taking ascent-override etc. into account), but then inside the line, using a scaled font which will operate at the decreased/increased font-size for how it behaves in shaping (scaled advances, shorter/longer text run results) and how it draws (smaller, larger glyphs).

[jfkthame]

My understanding is the intention is not to use a fully down- or upscaled font internally as that would affect the line height. As @jfkthame explains, ascent / descent would still be computed from font-size:,

Not quite. To clarify, my position is that ascent-override etc would continue to be computed based on the font-size, without regard to any glyph-scale-factor in effect; so if these descriptors are used to control line height, the glyph scaling will have no effect. But if ascent etc are not overridden by descriptors, the font's normal metrics will be affected by the scale factor.

which I think makes sense (otherwise what's the difference to using a different font-size: to start with?

This is not like using a different font-size because it is associated with an individual font face, not with an element property. So within a single element, styled with a single font-size, there might be multiple font faces in use (each covering a different script, for example), each of which could have its own different glyph-scale-factor, designed to visually harmonize the different designs.

It's also not like using a different font-size because it does not affect the size of the em unit, etc.

So perhaps it can be described from an implementation perspective as splitting the internal font object used for retrieving metrics for line height (ascent, descent) in layout from the one that we use to actually perform inline layout with, that we shape with, and that we shape with. Or perhaps more simply put: Keep line height, ascent, descent, baseline computations based on font-size: and original metrics at font-size: (taking ascent-override etc. into account),

As described above, I think that if the font is being queried for its normal ascent, descent, baseline, etc., these metrics should come from the scaled font so that they maintain their expected relationship with the glyph shapes. It's in the case when override descriptors are used to set them to specific values (expressed as percentages of font-size) that the scaling has no effect; an ascent of 80%, for instance, should remain at 80% of 1em regardless of the scaling of the glyphs relative to the em-square.

but then inside the line, using a scaled font which will operate at the decreased/increased font-size for how it behaves in shaping (scaled advances, shorter/longer text run results) and how it draws (smaller, larger glyphs).

[xiaochengh]

One subtle issue is that, what exactly is the value being overridden? It should not be the font-size property value, neither computed nor used, since they work at different levels and should better not have extra dependency.

While I agree with @jfkthame on the behavior details, I'd like to reiterate on this more fundamental question, and hope we can get a better answer.

So far, we've discussed various metrics/values that the proposed descriptor should or should not interact with. My concern is that this is not a clean way to write a definition, as in this way we need to specify the interactions with an exhaustive list of metrics/values, which we probably don't have. And it's error-prone.

That's why I proposed that the descriptor is a modification to the font selection algorithm in #6075 (comment). In this way it should satisfy all the detailed behaviors that @jfkthame proposed.

The definition I proposed still looks a bit hacky and is just borderline acceptable to me. I'll be happy to see a better alternative.

The proposal would be to add a descriptor taking a percentage and effectively functions the same as font-size-adjust for a given scale factor.

This doesn't look correct to me, as font-size-adjust is applied to the used font-size of the element instead of any font face. It also seems a bit risky since there are too many things depending on font-size...

[faceless2]

We think of font-size-adjust as a scaling factor applied to the rendered glyph and its advance, nothing more. It has no effect on em or any other units, so if the intention is for this property is to match the same behaviour I'd agree with @drott

It also seems a bit risky since there are too many things depending on font-size

precisely why I think this should have no impact on any metrics. So I'm a bit worried about this:

But if ascent etc are not overridden by descriptors, the font's normal metrics will be affected by the scale factor.

If we're going to be adjusting ch, ic etc. then how is that going to be applied to an element that contains two fonts in the font-family, one with scaling and one without? How much letter spacing is applied in this example?

@font-face {
    font-family: "foo";
    scale-factor: 2;
    unicode-range: U+41;
}
<div style="font-size: 10px; font-family: foo, serif; letter-spacing: 1ch">AB</div>

I think a clear distinction needs to be made between ascent-override etc. which are set in the @font-face and apply only to that family; and units, which apply to an element that may comprise of multiple font families. If the scaling factor applies to the former type of property, I don't really have an opinion but it's not going to be problematic either way. But I'm nervous about scaling applying to units in any way, because I don't see how it can be applied.

[faceless2]

On reflection, I'll answer my own question: the letter spacing in that example is whatever the width of "0" is in the first available font, which - because "foo" doesn't declare U+20 - is "serif". So I don't think this is an issue and I'll withdraw my concerns. As you were!

[jfkthame]

That's right -- and the same applies to all the units etc that are based on font metrics (like ch and ex): they don't vary according to which font face actually ends up getting used, which could be different for each character within the element, they're defined in terms of the "first available font" or similar language.

So if the first available font [for the specific character on which the measurement is based] has a glyph scaling factor in effect, that contributes to the metric it reports. But whatever the metric is, it's consistent throughout the element regardless of the mix of actually-used faces.

[xiaochengh]

We think of font-size-adjust as a scaling factor applied to the rendered glyph and its advance, nothing more.

I suppose we also need to scale the ascent, descent and line gap metrics, when used for line-height: normal?

And these seem enough for a good text layout, so I don't think we should have anything else affected.

[fantasai]

@drott This scaling needs to affect the baseline table, otherwise the glyphs won't actually line up. (The purpose of baseline tables is to get proper optical alignment across fonts. It can't do its job if you scale the table but not the glyphs or vice versa.)

@jfkthame The ascent/descent metrics are generally based on the size of the gyphs, right? They're there to show how much space to reserve for the glyphs. The main use case for adding overrides for them was because OpenType has multiple sets of ascent/descent metrics and platforms can't agree on which set of metrics to use, not because we needed arbitrary overrides; I expect most cases the override value will match one or the other built-in ascent value. As for effect on layout, the height of the line is based on line-height, which most people set explicitly anyway; if there's concerns about scaling affecting the line height, don't use line-height: normal. But I want this feature to work not just for cases where the font is not just a temporary fallback that will get erased in 5 seconds but also for cases where multiple fonts need to work together but their optical sizes don't match well without adjustment. Cases where this scaling factor is for a permanent, desired font. For those cases if the ascent-override is set to a value that corresponds to some typographic design reference for the glyphs, then that needs to scale with the glyphs.

@xiaochengh font-size-adjust is specifically defined to affect the "used font-size" (i.e. the one used to size and select the font) and not the "computed font-size" (i.e. the one used for inheritance and calculating em units etc.) for the same reasons as we're discussing here for the glyph size override. And we're careful about where we use "computed font size" rather than "used font size" for that reason (or should be, and should fix anywhere they're mixed up regardless). So I think these need to be kept in sync on how they behave, unless there's some particular reason why font-size-adjust and this feature need to be distinct in some particular detail in which case we can make that detail a well-considered exception.

[xiaochengh]

So I think these need to be kept in sync on how they behave, unless there's some particular reason why font-size-adjust and this feature need to be distinct in some particular detail in which case we can make that detail a well-considered exception.

(The following assumes "these" mean font-size-adjust property and the proposed descriptor)

I don't think the new descriptor should affect the font-size property value, neither computed nor used, because it is ill-defined. Assume we have an element that uses multiple font faces, some of which have this scale factor and some don't. Then they would want to set different used font-size values to the same element.

A similar idea is that, only the first available font's glyph scale factor affects the used font-size of the element. While being well-defined on its own, this means we can't use it to harmonize an element with mixed fonts. I don't think this is the desired solution...