1978248 - ff (ff) ligature is not displayed, e.g. in Boston Globe articles, on Samsung phones

Status: NEW

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

Description

[Amir Aharoni]

Attachment: Boston Globe bug - Firefox.png

Steps to reproduce:

Go to https://www.bostonglobe.com/2025/07/18/metro/commentary-ri-bikeshare-transportation/

The first sentence of the text is: It’s a hot summer day, and a Brown University student sets off across College Hill for their classes.

Note that the word "off" is not written with two letters f (Unicode codepoint 0066), but with an ff ligature (Unicode codepoint FB00).

Actual results:

When I open this article on Firefox for Android (140.0.4 Build #2016101263), I don't see the ff ligature. I just see blank space.

The same ligatures appears several more times on the same page, in the words affordable, coffee, efforts, effective, offering, and effort. In all of them, I see blank space.

In the end of the articles, the ligature appears in the word affairs, but this paragraph is italic, and the ligature is visible.

When I open the same page in Chrome on the same phone, I see all the letters. See the screenshots.

Expected results:

The ligature should be visible, and the word should be fully readable on Firefox.

A comment that might be useful: When I look at the page in Chrome, I see the ligature instead of an empty space, but it appears as if it's taken from a different font. So perhaps Firefox fails to display a fallback character, and Chrome succeeds.

Comment 1

[Amir Aharoni]

Attachment: Boston Globe bug - Chrome.png

Screenshot of the same page in Chrome on the same phone.

Comment 2

[Makoto Kato [:m_kato]]

What device and Android version do you test? I cannot reproduce this on Android 16 + Pixel 8a

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce on my Samsung A51 phone (running Android 13).

I can't reproduce on the Pixel devices that I've tested, though.

(This is a bit annoying to test now, because the Boston Globe pops up a splash screen after a short delay, which covers up the "ff")

I'll take a look a little bit later on and see if I can get a reduced testcase.

Comment 4

[Amir Aharoni]

I am using Samsung Galaxy S23 Ultra with Android 15.

Comment 5

[Daniel Holbert [:dholbert]]

DevTools says that paragraph is using these fonts, selected via the serif generic fallback:

Cutive Mono
Noto Serif

And this is the plain text, rendered with those fonts:

It’s a hot summer day, and a Brown University student sets off across College Hill for their classes. With the distance too far to walk comfortably and too short to justify a car ride, the student will be late, but this doesn’t have to be the norm.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (usable to test the bug if you view it locally or host it elsewhere, but the bugzilla-hosted copy renders "RMA" instead of "ff" for some reason)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 8

[Daniel Holbert [:dholbert]]

odd, the testcase is rendering differently on bugzilla (with backwards "RMA" special characters) vs. when I view it locally (where it shows "ff").

So the bugzilla-hosted version isn't an effective testcase right now, but I've got a working testcase (byte-for-byte identical) at https://dholbert.org/tests/1978248/test.html which has a ff ligature glyph that fails to render on my Samsung Galaxy A51.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

DevTools says that paragraph is using these fonts, selected via the serif generic fallback:

Cutive Mono

So that one (Cutive Mono) is what we're using to render the ff glyph here (and failing, maybe because that font doesn't have such a glyph [?]).

If I explicitly request to render the whole page using that font, Firefox dutifully does, but Chrome does not use that font at all:
https://dholbert.org/tests/1978248/test-cutive.html

Chrome's DevTools show me that it's using "RobotoStatic" instead (when I request CutiveMono). When I explicitly request to render the whole page using that font, everything looks fine even in Firefox:
https://dholbert.org/tests/1978248/test-roboto.html

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screencast of Firefox loading testcases from comment 8 and 9 (on Samsung A51)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screencast of Chrome loading testcases from comment 8 and 9 (on Samsung A51)

Comment 12

[Daniel Holbert [:dholbert]]

jfkthame, do you have any ideas about how to learn why we might be using this particular fallback-font when Chrome is not (and not even using it when explicitly asked to), on Android?

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #8)

odd, the testcase is rendering differently on bugzilla (with backwards "RMA" special characters) vs. when I view it locally (where it shows "ff").

So the bugzilla-hosted version isn't an effective testcase right now, but I've got a working testcase (byte-for-byte identical) at https://dholbert.org/tests/1978248/test.html which has a ff ligature glyph that fails to render on my Samsung Galaxy A51.

The UTF-8 representation of U+FB00 (the "ff" presentation-form ligature) is 0xef 0xac 0x80, which are the bytes in your file.

But bugzilla is serving it with content-type: text/html; charset=IBM866, which is the DOS Cyrillic code page, and hence those bytes get interpreted as "ямА".

Why is b.m.o doing that? Offhand, I don't know.

Viewing it in Firefox on desktop, at least, I can "fix" the rendering with the View / Repair Text Encoding command; then it reinterprets the file as UTF-8 and displays the expected "ff".

(But this is all something of a side issue, and doesn't address the font question....)

Comment 14

[Jonathan Kew [:jfkthame]]

As for the fonts: I found a copy of Cutive Mono (from Google Fonts; calls itself "Version 1.100"; I don't know if this is identical to what's on your device), and confirmed that it include U+FB00 in its character map, but the glyph is completely blank. It has the same advance width (1240 units) as the other glyphs in the font, but its outline data is empty.

So this is clearly a font bug.

FWIW, the next couple of presentation-form ligatures U+FB01 "fi" and U+FB02 "fl" do have outlines, but then U+FB03 "ffi" and U+FB04 "ffl" are again present but empty, and so will suffer from the same issue: the font will appear to be valid for those character codes, as far as the browser can tell, but they'll render as blanks.

Why we're using that font: I'm guessing that these presentation-form codepoints are not supported by Noto Serif (which is reasonable: there's generally no good reason for content to use those character codes, which only exist for legacy codepage round-trip compatibility). So we have to do a fallback search to find a font that can render them; and Cutive Mono happens to be the first font we find that supports them (according to its character map!).

As for why Chrome doesn't use Cutive Mono even if explicitly requested, I don't know... they may be overriding the device's collection of available fonts and making their own decisions about what to include/exclude.

AFAICT, this (broken) Cutive Mono font may have been present on a lot of Android devices for a long time, so the problem is probably quite widespread. Perhaps we should do something to explicitly block this font from the list we use.

(An aside: this is unwise authoring practice. Don't try to be "fancy" with presentation-form ligature codepoints. They'll often render poorly (e.g. falling back to a different font from the surrounding text, as noted at the end of comment 0). Rendering ligatures for "ff" etc when appropriate is the responsibility of OpenType fonts.)

Comment 15

[Jonathan Kew [:jfkthame]]

FWIW, I just tried this on a new Pixel 9a device, and there the ff ligature displays OK, because it uses a font called Arbutus Slab that does actually provide a visible glyph (although it doesn't quite match the surrounding Noto Serif; in particular, the "f"s have a much more pronounced bulb at the end of the curl).

If I explicitly ask for Cutive Mono, the problem still occurs: the font claims support for U+FB00, but still has a blank glyph.

Curiously, it seems that Noto Serif supports U+FB01 through U+FB04 (fi fl ffi ffl), but is lacking U+FB00 (ff). There doesn't appear to be any clear logic to this.

The case of Cutive Mono, which only has glyphs for U+FB01 and U+FB02 in that range, is more understandable: those are the two f-ligature presentation forms that were present in the old MacRoman character set, and so got quite widely implemented by font designers on that basis. So they're more often present than the other ligatures. The main problem with that font is that for some reason the other codepoints got added to the character map, so appear to be "supported", but no actual glyphs were created.

As for Noto Serif, it did extend things beyond the original two MacRoman ligature glyphs, but it seems they just overlooked U+FB00. Hence, fallback; and if the font that fallback finds is Cutive Mono, we lose.

Comment 16

[Daniel Holbert [:dholbert]]

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

FWIW, I just tried this on a new Pixel 9a device, and there the ff ligature displays OK [...]
If I explicitly ask for Cutive Mono, the problem still occurs:

Same for me, on Pixel 9 Pro XL (Android 16) and an old Pixel 4a (Android 13 -- notably same Android major-version as my Samsung phone that does repro the issue(.

AFAICT, this (broken) Cutive Mono font may have been present on a lot of Android devices for a long time, so the problem is probably quite widespread. Perhaps we should do something to explicitly block this font from the list we use.

Indeed -- I just tested my old Google Nexus 5 (Android 6.0.1) and it exactly matches my experience on Samsung -- i.e. Firefox on that device uses Cutive Mono as a fallback here, and hence renders https://dholbert.org/tests/1978248/test.html with an empty box (whereas Chrome on that device shows a ff glyph and doesn't use Cutive Mono even when I ask for it).

So this isn't just a Samsung-specific quirk and is probably somewhat widespread. I'll file a bug on blocking use of Cutive Mono as a system font.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew [:jfkthame] from comment #13)

But bugzilla is serving it with content-type: text/html; charset=IBM866 [...]

Why is b.m.o doing that? Offhand, I don't know.

Thanks! I filed a bug on that: bug 1980265.