Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values] Fallback value of ex height #5243

Closed
fantasai opened this issue Jun 19, 2020 · 10 comments
Closed

[css-values] Fallback value of ex height #5243

fantasai opened this issue Jun 19, 2020 · 10 comments
Labels

Comments

@fantasai
Copy link
Collaborator

In #814 (comment) @faceless2 wrote:

Another quick addendum as this doesn't warrant a post on it's own - but as I was just banging on about font metrics for 100 lines, it's relevant to note that the other significant metric extracted from the font is x-height, used for the "ex" unit and middle alignment. This is extracted from "OS2.sxHeight. If it is zero, Firefox, Chrome and Safari all set it to 0.8em - not the 0.5em currently recommended in css-values-4.

which does in fact deserve a post on its own. :)

@jfkthame
Copy link
Contributor

jfkthame commented Jul 1, 2020

If it is zero, Firefox, Chrome and Safari all set it to 0.8em

I'm a bit surprised by the 0.8em figure here; from what I see in the Firefox code, there are a few fallback options used on various platforms, including 0.5em (on Freetype-based platforms, Linux and Android) or 0.56*ascent (on macOS), or examining the actual ink bounds of an 'x' glyph if present. It may also use a value retrieved from OS font APIs (directwrite, core text), in which case exactly where the value comes from is opaque to us.

(A lot of this is, I think, historical baggage that could be cleaned up without too much harm.)

used for the "ex" unit and middle alignment

Perhaps worth noting that the x-height measurement is also important as an input to font-size-adjust computations. So changing how it is derived from the font (or the fallback used) could affect the used font size in cases where adjustment is in effect.

(FWIW, of the various fallbacks present in different parts of the Firefox code, I suspect the 0.56*ascent value was probably the one based most directly on observation of what worked well with actual fonts.)

@faceless2
Copy link

I'd derived that 0.8em figure a couple of years back, when I was still delving into font-metrics - I'd be a more specific about the platforms and fonts I tested with these days, not least because I now understand the variation across them! It's certainly based on the metrics tested on my Mac, and possibly not verified on other platforms.

@litherum
Copy link
Contributor

litherum commented Jul 1, 2020

WebKit does:

            Glyph xGlyph = glyphForCharacter('x');
            if (xGlyph)
                xHeight = -CGRectGetMinY(platformBoundsForGlyph(xGlyph));
            else
                xHeight = CTFontGetXHeight(m_platformData.font());

CTFontGetXHeight() uses a few different signals: OS2.sxHeight, the bounding boxes of representative characters, and additional heuristics. I don't think I can be more specific than that.

The spec should be flexible enough to:

  1. Not require browsers to parse font files themselves
  2. Not dictate the implementation of system-wide text libraries

@fantasai
Copy link
Collaborator Author

fantasai commented Jul 1, 2020

Fwiw, current spec text is

Equal to the used x-height of the first available font [CSS3-FONTS]. The x-height is so called because it is often equal to the height of the lowercase "x". However, an ex is defined even for fonts that do not contain an "x". The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "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 x-height, a value of 0.5em must be assumed.

@faceless2
Copy link

I've made some versions of Ahem with the "OS2.sxHeight" set to 0, and put a testcase up at https://jsbin.com/lexuren/edit?html,output

@astearns astearns removed the Agenda+ label Jul 1, 2020
@dbaron
Copy link
Member

dbaron commented Jul 1, 2020

@faceless2
Copy link

My apologies, I've sent this off in the wrong direction. On my Mac, when the OS2.sxHeight is set to 0 it appears to be falling back to some other metric in the font, which happens to be 0.8em. I haven't yet figured out which metric it is.

@Myndex
Copy link
Member

Myndex commented Mar 1, 2021

Hi @faceless2

My apologies, I've sent this off in the wrong direction. On my Mac, when the OS2.sxHeight is set to 0 it appears to be falling back to some other metric in the font, which happens to be 0.8em. I haven't yet figured out which metric it is.

It depends entirely on the specific font. 0.8em is approximately the cap-height for some.

AND: what is needed is an actual font-x-size: property that sets the font size BASED ON the font's x-height, not the other way around. !!!

@fantasai
Copy link
Collaborator Author

@Myndex You're looking for font-size-adjust. Go look it up.

Anyway, I'm closing out this issue since afaict, the spec doesn't need any changes.

@Myndex
Copy link
Member

Myndex commented Sep 30, 2021

@Myndex You're looking for font-size-adjust. Go look it up.

Anyway, I'm closing out this issue since afaict, the spec doesn't need any changes.

I am quite familiar with font-size-adjust, it does not do nor behave in the way needed for directly setting font size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants