1759667 - Issue rendering spaces and numbers for certain fonts on Linux [involves Noto Color Emoji font prepended to all font families]

Status: RESOLVED INVALID

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

Description

[Arne Brasseur]

Attachment: 2022-03-15_094311_firefox-nightly.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Open certain sites (Github, Google, Notion, and many others) on Firefox Nightly after March 7.

Actual results:

Spaces are rendered extremely wide, more like tabs, and numbers are rendered as emoji (?) numbers. This also affects part of the Firefox UI, e.g. tab titles have really wide spaces as well.

See screenshot:

https://gist.github.com/plexus/d15c4cdb67d7b69709958971110d9c13/raw/3c17ac36c2e6e788860417c0218df6645a6b7352/2022-03-15_094311_firefox-nightly.png

This started happening on nightly on March 7 (100.0a1 release) (https://twitter.com/plexus/status/1500792490751840263). Currently it seems beta is affected as well. Stable (98) is not.

This was happening on Kubuntu 21.04, and is still happening after upgrading to 21.10.

Maybe there's something funny going on with my installed fonts, but so far only Firefox seems to be affected.

Expected results:

https://gist.githubusercontent.com/plexus/d15c4cdb67d7b69709958971110d9c13/raw/3c17ac36c2e6e788860417c0218df6645a6b7352/2022-03-15_094242_firefox.png

Comment 1

[Arne Brasseur]

Workaround: seems the problem went away after uninstalling Noto Color Emoji (sudo apt-get remove fonts-noto-color-emoji). Seems for some reason it was picking glyphs from Noto over the glyphs from the specified font.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Daniel Holbert [:dholbert]]

This sounds very odd!

Might be related to bug 1759891, which was another case where we were using characters from the wrong fonts. That just had a fix land yesterday, so it should be fixed in today's Nightly.

Would you mind retesting this in Firefox Nightly under conditions where you would expect to see the bug (e.g. with Noto Color Emoji reinstalled)? Maybe/hopefully bug 1759891 fixed it.

If that bug didn't fix it, perhaps you could help us and use mozregression to identify the first-affected-build? It should end up producing a pushlog URL with a list of potentially-guilty commits. (And it should bisect further than just Nightlies, getting us to a pretty short guilty range.)

Comment 4

[Daniel Holbert [:dholbert]]

(I should also note: I do have the fonts-noto-color-emoji package installed on my Ubuntu system, but I have not encountered this particular bug that you describe here. So: despite what comment 1 might implicitly suggest, this is not as simple as "systems with fonts-noto-color-emoji are affected".)

Comment 5

[Jonathan Kew [:jfkthame]]

I strongly suspect this is a fontconfig-related issue. In bug 1759891, the problem was that we ended up (sometimes) rendering glyphs from an entirely different font from the one we used to do layout and text shaping, resulting in "random"/garbled text because glyph IDs are not in general interoperable between different fonts.

In this case, though, the actual layout is affected (e.g. the width of the spaces). What is happening, I think, is that when the color-emoji font package is present, there's a fontconfig alias or substitution rule that prefixes Noto Color Emoji before other family names when handling a fontconfig lookup -- during the FcConfigSubstitute call, I think. Maybe it's doing this for certain specific families, or maybe a generic rule that prefixes the emoji font in all cases. I've seen fontconfig files that have rules like this in a few emoji packages. I guess the intent is to ensure that the emoji font takes precedence over potential monochrome versions of smileys and other symbols that may be in the regular text font. But unfortunately, if the emoji font also covers standard characters such as digits (in order to implement emoji-style keycap sequences, probably) and even the space character, and these are all "wide" glyphs, that's pretty disruptive for normal text.

So while it's hard to confirm without checking details of the affected system (searching the fontconfig files for where there are alias rules that insert the emoji font), I'm fairly sure this is a result of how fontconfig is set up there.

There was a change in bug 1756400 (landed in Firefox 99) to how fontconfig substitutions are handled, and while in general that made us better at respecting the fontconfig settings, it's possible that it made the (poorly-designed, IMO) configuration here behave worse. (Previously, I suspect we may have simply been getting a default font because the explicit font-family request ended up getting ignored. But now we respect the font-family request, and then suffer from the fact that the fontconfig setup inserts the emoji font at the beginning of it.)

Comment 6

[Arne Brasseur]

Just reinstalled Noto Color Emoji and unfortunately this is still happening on Firefox 100.0a1 (2022-03-28).

Agreed that the presence of Noto Color Emoji is not sufficient to trigger this, I have a very similar setup on my laptop (Kubuntu+nightly) and haven't seen it there.

Maybe my fontconfig got into a funny state. I've tried a few things

• move ~/.config/fontconfig/fonts.conf out of the way
• move ~/.fonts out of the way
• reinstalled everything with files under /etc/fonts

$ dpkg -S /etc/fonts
fonts-vlgothic, fonts-tlwg-garuda, fonts-deva-extra, fonts-tlwg-waree, fonts-tlwg-typo, fonts-opensymbol, fonts-lohit-gujr, fonts-smc-karumbi, fonts-smc-dyuthi, fonts-noto-cjk, fonts-khmeros-core, fonts-linuxlibertine, fonts-droid-fallback, fonts-smc-manjari, fonts-orya-extra, fonts-lohit-telu, fonts-lohit-taml-classical, fonts-lohit-taml, fonts-lohit-guru, fonts-lohit-deva, kubuntu-settings-desktop, fonts-urw-base35, fonts-lohit-orya, fonts-lohit-knda, fontconfig-config, fonts-dejavu-core, fonts-pagul, fonts-crosextra-carlito, language-selector-common, fonts-telu-extra, fonts-beng-extra, fonts-tlwg-typist, fonts-noto-core, fonts-smc-keraleeyam, fonts-lohit-mlym, fonts-lohit-beng-assamese, fonts-tlwg-loma, fonts-tlwg-kinnari, fonts-smc-meera, fonts-gujr-extra, fonts-tlwg-mono, fonts-smc-uroob, fonts-smc-anjalioldlipi, fonts-hack, fonts-guru-extra, fonts-tlwg-umpush, fonts-tlwg-norasi, fonts-smc-suruma, fonts-smc-rachana, fonts-lohit-beng-bengali, fonts-tlwg-laksaman, fonts-noto-mono, fonts-smc-raghumalayalamsans, fonts-smc-chilanka, fonts-gubbi: /etc/fonts
$ sudo apt-get install --reinstall fonts-smc-rachana fonts-crosextra-carlito fonts-lohit-beng-bengali fonts-tlwg-laksaman fonts-lohit-mlym fonts-tlwg-kinnari fonts-vlgothic fonts-tlwg-umpush fonts-lohit-guru fonts-smc-karumbi fonts-smc-anjalioldlipi fonts-dejavu-core fonts-tlwg-mono fonts-tlwg-waree fonts-tlwg-norasi fonts-smc-chilanka fonts-noto-core fonts-linuxlibertine fonts-hack fontconfig-config fonts-tlwg-typo fonts-smc-manjari fonts-smc-keraleeyam fonts-lohit-telu fonts-gubbi language-selector-common fonts-smc-dyuthi fonts-opensymbol fonts-khmeros-core fonts-lohit-knda fonts-lohit-beng-assamese fonts-urw-base35 fonts-lohit-taml fonts-pagul fonts-telu-extra fonts-lohit-orya fonts-tlwg-loma fonts-noto-mono kubuntu-settings-desktop fonts-tlwg-typist fonts-tlwg-garuda fonts-noto-cjk fonts-lohit-taml-classical fonts-droid-fallback fonts-smc-uroob fonts-smc-suruma fonts-smc-raghumalayalamsans fonts-smc-meera fonts-orya-extra fonts-lohit-gujr fonts-lohit-deva fonts-guru-extra fonts-gujr-extra fonts-deva-extra fonts-beng-extra

each time followed by fc-cache -rv and a restart of nightly. So far not seeing any difference. Any more suggestions on how I could "factory reset" my fontconfig? Would it make sense to share my /etc/fonts/conf.d?

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Jonathan Kew [:jfkthame]]

Yes, if you could zip up your /etc/fonts/conf.d, assuming there's nothing sensitive/confidential in there, and attach it here, that might help us identify exactly what's causing this.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #7)

The severity field is not set for this bug.

(Leaving this unset for the moment, in the hopes that we'll soon learn more about the conditions involved here & get a better idea of impact; we can make a severity assessment at that point.)

Comment 10

[Arne Brasseur]

Attachment: /etc/fonts tarball

A bundled up version of my /etc/fonts as requested.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Jonathan Kew [:jfkthame]]

(In reply to Arne Brasseur from comment #10)

Created attachment 9269995 [details]
/etc/fonts tarball

A bundled up version of my /etc/fonts as requested.

Thanks. OK, I think the source of the problem is this fragment:

        <match target="pattern"> 
                <edit name="family" mode="prepend"> 
                <string>Noto Color Emoji</string> 
                </edit> 
        </match> 

at the end of your /etc/fonts/local.conf.

As I understand it, this means that every "pattern" we pass to fontconfig to look up available fonts gets the name "Noto Color Emoji" inserted before (mode="prepend") whatever font-family we were intending to ask for. And that means that any character that's supported by Noto Color Emoji -- such as the digits or the space -- will be taken from that font instead of the one we really wanted.

Do you know where this /etc/fonts/local.conf comes from? If you remove it, or at least comment out this fragment of it (the other rules in it are about hinting/antialiasing settings, so you may want to keep those), does that fix the problem?

(Googling a bit, I found an old Reddit post at https://www.reddit.com/r/linux/comments/ao0mp3/how_to_better_enable_color_emojis/ that advised exactly this /etc/fonts/local.conf setup, maybe you followed similar advice at some point? In my opinion that was a poorly-designed recommendation, because in effect it overrides far too much.)

Comment 13

[Arne Brasseur]

I'm very sorry for sending people on this goose chase. I must have indeed followed some ill founded advice in the past. I've removed the local.conf and re-installed Noto and things are working fine.

Thanks a lot for your help!

Comment 18

[Thomas D. (:thomas8)]

Fwiw, recent duplicate bug 1777701 has screenshots showing the effects of this in Thunderbird 102:
attachment 9287117 [details], attachment 9287118 [details], attachment 9287119 [details], attachment 9287121 [details]