Closed Bug 1414384 Opened 7 years ago Closed 4 years ago

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

Categories

(Web Compatibility :: Site Reports, defect, P5)

x86_64
Linux
defect

Tracking

(firefox58 affected)

RESOLVED WORKSFORME
Tracking Status
firefox58 --- affected

People

(Reporter: botond, Unassigned)

References

()

Details

Attachments

(2 files)

STR:
  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.
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).
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.)
Thanks - moving to Tech Evangelism as per comment 4.
Component: Graphics: Text → Desktop
Product: Core → Tech Evangelism
Please have a look at this one, Oana.
Flags: needinfo?(oana.arbuzov)
Priority: -- → P5
The issue is still reproducible and only for the responses of Herb Sutter.

Affected area:
<p>
 H: Thanks, though it’s still a long-term experiment in early stages. I’d emphasize that the real “hottest topics”, new features that are actively being standardized in the near term, are concepts and modules. Those are rightly getting our attention and emphasis in the committee, so I hope people focus much more attention on those. We just added most of the Concepts TS to draft C++20! Modules and coroutines would be very nice major improvements to get into C++20 too, and I hope they may make it. All of those features are important because they help to simplify the way we write (and build) code by helping us write it more directly.
<br>
<span id="more-4383"></span>
</p>

The issue is not reproducible on Chrome.

Browser / Version: Firefox Nightly 61.0a1 (2018-05-01)
Operating System: Linux Ubuntu 16.04
Added screenshot with difference between Firefox and Chrome
Flags: needinfo?(oana.arbuzov)
Product: Tech Evangelism → Web Compatibility

I retested the issue and I am unable to reproduce it. The letters have the same height after zooming to 120%.

https://i.imgur.com/E8Js3nU.png

Tested with:
Browser / Version: Firefox Nightly 85.0a1 (2020-11-17)
Operating System: Pop!_OS 20.04

I'll close the issue accordingly.

If the issue still reproduces for you, Botond Ballo, feel free to reopen it.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

Does not reproduce for me either. It looks like this was fixed on the site side (they use a different font now).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: