[css-fonts-5] font-size-adjust with missing metrics

When the metric needed for font-size-adjust cannot be derived from the font (e.g. metric isn't registered / necessary glyphs are missing), what do we do?

The units fall back to some magic number, but probably for font-size-adjust we should just not adjust the font’s size.

Relatedly, for the from-font keyword, should we be picking from the first available font that is able to provide the desired metric?

Indeed, no adjustment when missing glyphs / metrics is probably the correct thing to do. "Best guess" fallback values are not particularly likely to be close to what the font actually looks like, and will as easily be too big or too small. Some of the time, the adjustment would end up being in the right direction, but it would be just as likely to do the opposite of what you want.

For ic, 1em is the correct size for the vast majority of CJK fonts, so it might still be tempting to synthesize the missing measurement to that value, but then again, if your font is missing a glyph for 水, how likely is it that it actually is a CJK font?

For ic, 1em is the correct size for the vast majority of CJK fonts, so it might still be tempting to synthesize the missing measurement to that value, but then again, if your font is missing a glyph for 水, how likely is it that it actually is a CJK font?

If it's a CJK font that has been subsetted to optimize for specific content, it could well have lost its 水.

For ic, 1em is the correct size for the vast majority of CJK fonts, so it might still be tempting to synthesize the missing measurement to that value, but then again, if your font is missing a glyph for 水, how likely is it that it actually is a CJK font?
If it's a CJK font that has been subsetted to optimize for specific content, it could well have lost its 水.

An actual case found in the market is fonts that only support Kana. They do not contain the character "水" and they are typically full-width.

Another viable approach would entail establishing fallback values for each font metric by referencing the existing fallback values utilized by browser engines, as discussed in #8792. For instance, both Blink and Webkit rely on the sum of ascent and descent for the advance height of 水 when 水 or vertical glyph information is unavailable.

Implement the ic-height metric of font-size-adjust

I am in favor of a behavior of "no adjustment" when the metric is not available.

no adjustment when missing glyphs / metrics is probably the correct thing to do

I am in favor of a behavior of "no adjustment" when the metric is not available.

I agree, this seems like the correct approach to me.

It seems to me that ic-height would be expected to parallel the behavior of the ic unit in vertical writing mode, for which Values and Units defines a fallback of 1em if the "real" metric cannot be determined.

In scaling or using a unit in calc() expressions ic-height needs to map to a number. But performing font-size-adjust to a heuristic does not make sense to me, it results in somewhat random behavior. In this context we have an alternative of not performing any adjustment. If it desired to use font-size-adjust to scale to any fixed values, separate unit types or percentage values can be used.

So, we currently have:

from-font
Computes to the <number> corresponding to the specified metric of the first available font.

Proposed resolution (the "no adjustment" option):

from-font
If the specified metric exists, computes to the <number> corresponding to the specified metric of the first available font. Otherwise, the same as none

@svgeesus

Thanks for the proposal, that sounds good to me for from-font. In addition, since we have both [ from-font | [<number [0,∞]>] isn't there a case for the [<number [0,∞]>] case to fail as well if the metric is unavailable. I would suggest to either add text for unavaiable metric there as well (=none when not available), or to pull up the text for "if the metric doesn't exist" above both.

Edit: Meant to say unavailable, instead of available. Looks like you understood that right despite, @svgeesus
despite the typo.

since we have both [ from-font | [<number [0,∞]>] isn't there a case for the [<number [0,∞]>] case to fail as well if the metric is available.

Yes, indeed.

Apply a fallback for font-size-adjust: ic-height when a required font…

Bug 1903710 [wpt PR 46836] - Apply a fallback for font-size-adjust: i…

Apply a fallback for font-size-adjust: ic-height when a required font…

@jfkthame

@jfkthame @drott Where are these "same heuristics" defined?

<emeyer> …Therefore, if the metric is missing, we should use the same heuristics we use for units for ex or cap when the metrics aren't available

Values 3 has some possible wording, but very handwavey. For example for missing cap height:

However, a cap is defined even for fonts that do not contain Latin letters. The cap-height of a font can be found in different ways. Some fonts contain reliable metrics for the cap-height. If reliable font metrics are not available, UAs may determine the cap-height from the height of an uppercase glyph. One possible heuristic is to look at how far the glyph for the uppercase “O” extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the cap-height, the font’s ascent must be used.

I can link to that for now, but the result is unlikely to be testable or interoperable even on the same platform.

Bug 1869667 [wpt PR 43637] - Implement the ic-height metric of font-s…

Bug 1903710 [wpt PR 46836] - Apply a fallback for font-size-adjust: i…

[css-fonts-5] Clarified that if "from-font" references a metric which…

Navigation Menu

Repository navigation

[css-fonts-5] font-size-adjust with missing metrics #6384

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-fonts-5] font-size-adjust with missing metrics #6384

Description

Activity

fantasai commented on Jun 15, 2021

frivoal commented on Jun 16, 2021

jfkthame commented on Jun 16, 2021

kidayasuo commented on Oct 17, 2023

shivamidow commented on Feb 8, 2024

drott commented on Feb 13, 2024

svgeesus commented on Feb 13, 2024

jfkthame commented on Feb 14, 2024

drott commented on Feb 14, 2024

svgeesus commented on Feb 26, 2024

drott commented on Feb 27, 2024

svgeesus commented on Feb 27, 2024

33 remaining items

svgeesus commented on Jan 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions