"r" at "s" characters are too short at 120% full-zoom on CLion blog



Tech Evangelism
19 days ago
18 days ago


(Reporter: botond, Unassigned)



Firefox Tracking Flags

(firefox58 affected)




(1 attachment)



19 days ago
  1. Run Firefox (any version) on Linux. I'm running Debian 9.
  2. Load https://blog.jetbrains.com/clion/2017/11/towards-a-more-powerful-and-simpler-cpp-with-herb-sutter/
  3. Set the full-zoom to 120%
  4. Look at the text in the blog post (specifically, the  
     answers to the interview questions)

Expected results:
  "r" and "s" characters are the same height as e.g. "e" and "m".

Actual results:
  "r" and "s" characters are shorter than e.g. "e" and "m"

This is not a regression as far as I can tell (happens as far back as Firefox 24), but it doesn't happen in Chromium on Linux, and it doesn't happen in Firefox on Windows.


19 days ago

Comment 1

19 days ago
Created attachment 8925121 [details]
Screenshot of buggy text rendering

This is a screenshot that shows the text rendering at 120% zoom.
I think this is, at least to some extent, an artifact of Freetype's autohinting, combined with a "trick" the site is using to try and make it more difficult for people to extract the webfont used.

They're using "Gotham SSm", but inspecting the page shows that the font is actually embedded as two separate fonts, "Gotham SSm A" and "Gotham SSm B". Each of these contains only a subset of the complete character set. Then they set
    font-family: "Gotham SSm A", "Gotham SSm B", Helvetica, Arial, sans-serif;

in the CSS, and the individual characters of text will be rendered some from the "A" font and some from "B", according to which actually contains them.

The trouble with this is that when Freetype's auto-hinting is enabled, it will aim to harmonize the heights of related glyphs (such as lowercase Latin) across all the glyphs in a font (such as "Gotham SSm A"), but it does NOT know anything about the relationship between these two separate faces. And so it's entirely possible for the auto-hinter to pick different pixel heights to "snap" the x-height of these two faces.

You don't see the problem on Windows because Windows is (I guess) using hinting that's present in the fonts, and that is common to both the "A" and "B" faces (because they were derived from a single master font). Most likely Chromium is using different Freetype options (or even a different Freetype version than we have in Firefox), which could also affect the results. But the root of the problem is that the site is using a weird and potentially disruptive technique to try and "protect" their font resources, which is hurting both performance (because half the time, we don't find the character required in the first font, and have to fall back to the next face; and so the text is being rendered as lots of tiny glyph runs in alternate fonts) and appearance (because the two faces are rasterized separately and may end up subject to different hinting heuristics).

Comment 3

18 days ago
Thanks for the analysis, Jonathan! Do you think we should treat this as a Tech Evangelism bug, then?
Yes, I think so -- it's either that, or just ignore it. I don't think there's anything actionable here on our side. (You could try tweaking your font rendering settings, as the results are probably dependent on hinting/antialiasing options, but that's purely local to your system, not something we can "fix" in Gecko.)

Comment 5

18 days ago
Thanks - moving to Tech Evangelism as per comment 4.
Component: Graphics: Text → Desktop
Product: Core → Tech Evangelism
You need to log in before you can comment on or make changes to this bug.