Closed Bug 1758315 Opened 3 years ago Closed 3 years ago

Too thin numbers on the verge on Android

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
100 Branch
Tracking Flags:
Tracking Status
firefox99 --- fixed
firefox100 --- fixed

People

(Reporter: emilio, Assigned: jfkthame)

References

(
URL
)

Details

Attachments

(9 files)

Firefox.jpg
601.22 KB, image/jpeg
Details
Chrome.jpg
579.76 KB, image/jpeg
Details
Test-case
165 bytes, text/html
Details
Roboto-Regular.ttf
2.26 MB, font/ttf
Details
RobotoStatic-Regular.ttf
298.49 KB, font/ttf
Details
SysFont-Myanmar.ttf
7.47 KB, font/ttf
Details
fontinfolog.txt
108.40 KB, text/plain
Details
GVE+patch
309.32 KB, image/jpeg
Details
Bug 1758315 - Call SetupVariationRanges when initializing font attributes in the FT2 font-list, to handle installed fonts with variation axes. r=emilio
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
Details | Review
Attached image Firefox.jpg —

I haven't yet dug on why, but happens both in Release and Nightly.

On the bug URL, and any other article on the site, numbers look oddly thin, see screenshot.

Attached image Chrome.jpg —

Haven't checked if it happens on desktop either (filing from phone). Ni?ing to check but if any of you are faster be my guest :)

Flags: needinfo?(emilio)

Looks fine on desktop (macOS) for me. It'd be interesting to know what font it's using for that content on your phone. (On desktop, I'm getting the system's standard Helvetica, via font-family: Helvetica, sans-serif, but that's not a Helvetica face in your screenshots; is it a standard font on your device, or are they serving you a webfont?)

Yeah, so it's not a web font, it's the same CSS rule what's determining the font-family. On the fonts panel, I see that the fonts used are "Roboto" for most text, and "Roboto Thin" for spaces and numbers, which is odd.

Based on that it's a font selection issue, so adjusting component accordingly.

Component: Graphics: Text → Layout: Text and Fonts

I don't see the issue on a simple page like:

<!doctype html>
<meta name=viewport content="width=device-width">
<style>
  :root { font-family: Helvetica, sans-serif; }
</style>
<p>ABC 123 DEF 456

So something else is clearly going on.

Ah, .c-entry-content also has font-weight: 300;, and with that it repros.

Attached file Test-case —

It doesn't happen on Linux if I specify font-family: Roboto explicitly. There we choose consistently the "thin" face.

Looks like your device has a Roboto Thin face that only includes numbers, not letters. What a strange thing for the vendor to decide to do.

Can you pull a copy of the Roboto-Thin font file from the device so that we can double-check that's really what is going on?

I'm also curious to see a list of the full collection of Roboto faces in /system/fonts on your device. It looks like Chrome is using a Roboto Light face (which has the full character set), but for some reason we're not getting that weight. Maybe bad metadata in the font files? Maybe Chrome ships its own separate set of fonts?

If there's a Roboto-Light.ttf (or similar) in your /system/fonts, I'd like to have a look at it to see if we can figure out why we're ignoring it here.

Fonts there are:

$ cd /system/fonts
$ ls -la | grep -i roboto                                                                                                                                                                                      
lrw-r--r--  1 root root       18 2022-01-18 12:44 DroidSans-Bold.ttf -> Roboto-Regular.ttf
-rw-r--r--  1 root root  2372548 2022-01-18 12:44 Roboto-Regular.ttf
-rw-r--r--  1 root root   305656 2022-01-18 12:44 RobotoStatic-Regular.ttf
Attached file Roboto-Regular.ttf —

Yuck.... looks like somebody decided to package all the faces of Roboto into a single "variable" font, but it's not well executed; it doesn't actually vary the weight smoothly from font-weight: 100 to font-weight: 900, it just jumps abruptly between the original discrete weights of the non-variable family at particular values in the input coordinate space. (To experiment with the font, I installed in locally on Linux desktop. Note that if you already had Roboto installed on desktop, it may well not be the same version.)

[edit: turns out at least part of the issue here is actually a Gecko bug; see comment 24]

On Linux, I'm seeing somewhat different behavior between Chrome and Firefox with this font; it seems the rendering steps from one weight to another at different values of the input weight coordinate. I suspect this may be to do with the avar table in the font; I recall seeing another report recently that suggested there may be bugs in how this is handled.

I also tried the font on both macOS and Windows; it looks to me like FreeType may disagree with Core Text and DirectWrite on the handling of the variation axis.

None of this explains why you're seeing the digits behaving differently from the letters, though. That's really weird.

Hmm. Another interesting thing: if I load that same Roboto font as a webfont with @font-face, it behaves better. So something about how we're handling it as an installed font may be messed up. OK, that could be a real Gecko bug.

The letters vs numbers thing still makes no sense to me, though.

Ok, so I took some logs from my android device. With GVE the bug also repros and loading the test-case I see:

3-07 19:56:20.941 30922 30980 I Gecko   : [Child 30922: Main Thread]: W/textrun (textrun) fontgroup: [sans-serif] default: sans-serif lang: x-western script: 25 len 15 weight: 300 stretch: 100% style: normal size:  48.00 1-byte TEXTRUN [ABC 123 DEF 456] ENDTEXTRUN
03-07 19:56:20.941 30922 30980 I Gecko   : [Child 30922: Main Thread]: D/textrun (textrun-fontmatching) fontgroup: [sans-serif] default: sans-serif lang: x-western script: 25 [0:3] /system/fonts/Roboto-Regular.ttf (list) [3:8] /system/fonts/SysFont-Myanmar.ttf (list) [8:11] /system/fonts/Roboto-Regular.ttf (list) [11:15] /system/fonts/SysFont-Myanmar.ttf (list)

That is... unexpected?

Attached file SysFont-Myanmar.ttf —

So that's a "Roboto Thin" font that only has glyphs for numbers and some punctuation afaict.

Sheesh. Whoever thought that was a good idea?!?!

Presumably this is meant for a Myanmar-localized device, which will use some other font for the actual script, but they decided they'd need a "system font" with numbers in order to display the time on the lock-screen, or something like that. So they took a chainsaw to Roboto Thin and dumped the mutilated remains into /system/fonts, retaining the original font name -- that's a recipe for confusion.

Looks like we have some font-list logging under the fontInfoLog module name; can you capture that? Maybe there's some reasonable way we can arrange to prefer the "real" font over this junk.

Attached file fontinfolog.txt —

It seems that's the only Roboto face with weight of 250 in my system :(

The Chromium font distance algorithm seems a bit more involved than just distance between the weights, though I haven't checked if they get a different result than us: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/fonts/font_selection_algorithm.cc;l=98;drc=e93f480dcacd119a7709495797228e6744761c73

Flags: needinfo?(emilio)

(In reply to Jonathan Kew (:jfkthame) from comment #15)

Yuck.... looks like somebody decided to package all the faces of Roboto into a single "variable" font, but it's not well executed; it doesn't actually vary the weight smoothly from font-weight: 100 to font-weight: 900, it just jumps abruptly between the original discrete weights of the non-variable family at particular values in the input coordinate space.

To set the record straight somewhat, further testing suggests that the variable Roboto isn't as weird as I first thought: it does allow continuous weight variation, for example. We're not currently doing a good job of handling its style properties/axes when it is installed as a system font. I'll try to look into whether we can improve things there.

The problem of the numbers-only Roboto Thin font on your device is another matter; that's a really poor decision by the device vendor, IMO. (At least I assume it's the vendor who is responsible for this.) They should have renamed the font to give it a unique name that doesn't merge it with the "real" Roboto family. (Or they could've kept it out of the system fonts directory and just loaded it explicitly by pathname in whatever piece of software wants to use it.)

I've pushed a try run at https://treeherder.mozilla.org/jobs?repo=try&revision=44867580fe80238b7607210b7d00bef4e87bf966 with a patch that might help here; @emilio, if you could test this and see what difference it makes, that'd be great - thanks!

Flags: needinfo?(emilio)
Attached image GVE+patch —

That does help, thanks!

Flags: needinfo?(emilio)

FWIW that's on https://crisal.io/tmp/sans-serif-android.html. It seems we make some different decisions to Chrome when handling web fonts, but those repro on Desktop too.

It seems we make some different decisions to Chrome when handling web fonts, but those repro on Desktop too.

Yeah, that's because in Chrome a rule like

  @font-face {
    font-family: Roboto-WebFont;
    src: url("Roboto-Regular.ttf");
  }

will result in a family with a single fixed-weight face (because the initial value of the font-weight descriptor is normal). So the variability of the font is lost. To treat it as a variable face you'd have to say

  @font-face {
    font-family: Roboto-WebFont;
    src: url("Roboto-Regular.ttf");
    font-weight: 100 900;
  }

and then it'll match Firefox (and Safari) behavior.

The CSSWG resolved that the initial value of the descriptor should be auto rather than normal, so that simple usage of variable fonts will work as an author would expect, but it doesn't look like Blink supports this yet.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/405d0e8c4e6c Call SetupVariationRanges when initializing font attributes in the FT2 font-list, to handle installed fonts with variation axes. r=emilio

https://hg.mozilla.org/mozilla-central/rev/405d0e8c4e6c

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox100: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

Comment on attachment 9266866 [details]
Bug 1758315 - Call SetupVariationRanges when initializing font attributes in the FT2 font-list, to handle installed fonts with variation axes. r=emilio

Beta/Release Uplift Approval Request

  • User impact if declined: Bad font rendering in some modern Android devices.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): One-liner initializing variable fonts for locally-installed fonts.
  • String changes made/needed: none
Attachment #9266866 - Flags: approval-mozilla-beta?

Comment on attachment 9266866 [details]
Bug 1758315 - Call SetupVariationRanges when initializing font attributes in the FT2 font-list, to handle installed fonts with variation axes. r=emilio

Approved for 99.0b4. Thanks.

Attachment #9266866 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Regressions: 1798036
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: