- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Apr 2021 10:39:24 +0000
- To: public-css-archive@w3.org
> Suggested initial list: `ex`, `cap`, `ic`, `ch`. (With `ex` being the implied default, of course.) Yes, these seem a good starting point. (Do we want to use these short names that look like units, or would it be more readable to use `ex-height`, `cap-height`, `ic-width`, `ch-width`?) > I'm a little concerned about adding `ascent` or `extent`; a number of fonts have excess ascent to leave space for diacritics and stuff, and that extra space is a substantial proportion of the ascent of other fonts that cut the metric right at the Latin typographic ascent. So you'll get crazy results, depending on the fallback stack. In general for visually harmonizing a mixture of fonts, it's more important to consider the height than the advance of the glyphs, so in practice I think `ascent` and `extent` are more useful measures than `ch` or `ic` (with the possible exception of monospaced situations where the desire is to maintain consistent advances -- which *does* often apply to CJK, of course, and so `ic` has its place). It's true that results may be quite variable, depending how font designers have set their metrics; but that's a risk even with something as "simple" as ex-height, given that it is not always set accurately in fonts (just this week I ran into a case where the sxHeight field in the font was only about 1/3 of the actual ex-height of the glyphs, with the result that `font-size-adjust` makes that face huge). And when it comes to non-Latin faces, where any "ex" or "cap" height may be quite arbitrary, adjusting based on `ascent` or `extent` probably has *at least* as good a chance of being useful. Moreover, I could imagine an author finding this useful for webfont resources, where `ascent-override` and `descent-override` could be used to determine what should be regarded as each font's "extent", overriding the whims of designers; then `font-size-adjust: extent <number>` would work nicely to harmonize multiple webfonts (e.g. a set of faces covering a range of different scripts). (That would be largely equivalent to using `size-adjust` to tweak the scaling of each face, but expressing it in terms of setting the ascent/descent of each face and then letting `font-size-adjust` figure out the relationships might be convenient for a designer. It would also have the potential benefit of at least trying to do something reasonable with any system fallback font that may get involved, subject to the variability depending on how that font's designer chose to set the extent.) So I'd be in favor of including `ascent` and `extent`, despite the fact that they'll be less than perfect. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6160#issuecomment-818635794 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 April 2021 10:39:27 UTC