- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 May 2024 17:01:31 +0000
- To: public-css-archive@w3.org
> > If an author sets font-size-adjust to something other than none, they're expecting a "harmonization" of some aspect of font sizes to happen. > > I totally agree with this expectation. But do they get an accurate harmonization, or something random because different browsers use actually different heuristics? And does that help the author at all, or does it not instead cause more interop frustration? I'd argue that even if the first available font didn't provide a "real" metric, and so a synthetic/heuristic fallback was used, the author's primary goal of ensuring that fallback fonts end up with a visually similar size (as judged by the selected metric) is better served by this than by turning adjustment off altogether. > Let's look at the cap height heuristic: https://drafts.csswg.org/css-values-4/#cap says: > > > If reliable font metrics are not available, [UAs](https://drafts.csswg.org/css-2023/#user-agent) 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. > > "may... from upercase glyph"... "letter O"... "One possible heuristic.... " ... "otherwise ascent". > > This is not the kind of spec text that gets a closer to interop. Fair point, but that's a much wider issue than just font-size-adjust; it implies that the `cap` unit (for instance) is not reliably interoperable. If this kind interop for font-related measurements is important, then we need to address the fact that the result of `border-width: 1cap` or `height: 20cap` currently depends on "may... one possible heuristic... otherwise..." spec text. If that's good enough for the `cap` unit, I'd say it's good enough for `font-size-adjust` as well. And if not, we should fix it globally, not introduce divergence between the unit and the size-adjust factor. > If the emoji font does not have a cap height (unlikely): Then we go about inventing one by each UA employing their own different non-interoperable heuristics. Then we force-scale MyLatinFont and MyCyrillic font to match the heuristically determined value. This may very well result in the uppercase Cyrillic and Latin glyphs not matching the visual emoji cap height. > > I wonder what is gained with this method compared to just scaling by font size? What's gained is that the uppercase Latin and uppercase Cyrillic can still be expected to align, even if the emoji font didn't provide a meaningful cap-height. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-2098911245 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 7 May 2024 17:01:33 UTC