FS#65528 - [noto-fonts-emoji] Using font as fallback for Noto family break regular numbers and spaces rendering

Attached to Project: Arch Linux
Opened by Raphael Bialon (rbialon) - Monday, 17 February 2020, 13:02 GMT
Last edited by Antonio Rojas (arojas) - Wednesday, 25 March 2020, 14:16 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
When having only extra/noto-fonts-emoji installed, but not extra/noto-fonts, noto-fonts-emoji will be used as a fallback as introduced in https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/noto-fonts-emoji&id=b4b9b38c2c304824b6ea3dd069bdca179b316712 .
This breaks website rendering in Firefox, for example, as can be seen here https://imgur.com/a/Eo8KfBu because "Noto Emoji" is now matched for "Noto Sans":

$ fc-match "Noto Sans"
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"

Google Chrome and Chromium seem to ship with their own Noto fonts, as websites are still rendered correctly.

While noto-fonts-emoji renders alphabetic characters correctly still, it uses Emoji Numbers and apparently different whitespace than regular Noto fonts.


Additional info:
* Introduced in Version: 20191016-3
* Introduced in commit b4b9b38c2c304824b6ea3dd069bdca179b316712
* Screenshot of broken website https://imgur.com/a/Eo8KfBu

Steps to reproduce:
* Install noto-fonts-emoji, but not noto-fonts
* Visit https://gitlab.com/gitlab-org/gitlab/issues in Firefox (73.0)
This task depends upon

Closed by  Antonio Rojas (arojas)
Wednesday, 25 March 2020, 14:16 GMT
Reason for closing:  Fixed
Comment by Antonio Rojas (arojas) - Monday, 17 February 2020, 13:51 GMT
Meh, this is gitlab hardcoding their font...
Comment by Raphael Bialon (rbialon) - Monday, 17 February 2020, 13:56 GMT
Yes, another example I found was Trello who require "Noto Sans", too:

font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Noto Sans,Ubuntu,Droid Sans,Helvetica Neue,sans-serif;

See https://imgur.com/a/AJOIXCP
Comment by Chih-Hsuan Yen (yan12125) - Tuesday, 18 February 2020, 03:19 GMT Comment by Chandradeep Dey (chandradeepdey) - Friday, 21 February 2020, 13:20 GMT
I uninstalled all Noto fonts other than Noto Color Emoji, set all fonts in KDE settings to Source Sans Pro/Source Code Pro, and changed /etc/fonts/local.conf to use Source Code Pro/Source Sans Pro/Source Serif Pro. Couldn't reproduce your issue on the linked website.
Comment by Chandradeep Dey (chandradeepdey) - Friday, 21 February 2020, 13:26 GMT
Also, post the first 3-5 lines of output of "fc-list ':charset=31'" (U+31 DIGIT ONE).
Comment by Raphael Bialon (rbialon) - Friday, 21 February 2020, 14:10 GMT
Here is the output of "fc-list ':charset=31'" with noto-fonts installed: https://pastebin.com/2pR4iPuN
And here it is without noto-fonts installed: https://pastebin.com/kpVwJfgR

Noto Color Emoji appears only on line 199 (of 212):

$ fc-list ':charset=31' | grep -in noto
199:/usr/share/fonts/noto/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular
Comment by Moritz J (jomority) - Friday, 21 February 2020, 16:36 GMT
I am also affected on Qwant (e.g. https://www.qwant.com/?q=test%202020 ) with package version >= 20191016-2 (with 20191016-1 the site displays as expected).

I have the following noto packages installed: noto-fonts, noto-fonts-cjk, noto-fonts-emoji

They use the font string "Helvetica,Arial,Noto Sans,Ubuntu,sans-serif".
Comment by Chandradeep Dey (chandradeepdey) - Saturday, 22 February 2020, 08:52 GMT
So @rbialon you have the issue with noto-fonts not installed but noto-fonts-emoji installed. the issue goes away when noto-fonts is installed, i presume.
@jomority has the issue with noto-fonts and noto-fonts-emoji installed.
I couldn't replicate the issue with noto-fonts either installed or not installed.
¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯¯\_(ツ)_/¯
@rbialon see if the outputs of fc-match 'serif', fc-match 'sans-serif', fc-match 'emoji', fc-match 'monospace', fc-match 'system-ui' are all what you expect them to be
@jomority are you sure the bug exists in 20191016-3 and not only in 20191016-2?
Comment by Moritz J (jomority) - Saturday, 22 February 2020, 19:17 GMT
Hi, I investigated a bit further: My problem also appears in 20191016-3.
However, I'm not sure anymore if it's the packages fault.

The font-family property specified by the CSS is:
> "Helvetica, Arial, Noto Sans, Ubuntu",sans-serif

If I change it to
> "Helvetica", "Arial", "Noto Sans", "Ubuntu",sans-serif
in the inspector, everything works as expected.

I don't know if this is the fault of Qwant, Firefox or this package. Maybe someone with more knowledge of fontconfig can tell me if I should report this as a bug to Qwant.
Comment by Raphael Bialon (rbialon) - Sunday, 23 February 2020, 09:15 GMT
@chandradeepdey Yes, the mentioned behavior only occurs when noto-fonts is not installed. As it takes some disk space I'd rather avoid installing it, but I can also accept that the complete font set (noto-fonts and noto-fonts-emoji) has to be installed.

The output of fc-match is what I would expect it to be:
$ fc-match serif
DejaVuSerif.ttf: "DejaVu Serif" "Book"
$ fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"
$ fc-match emoji
NotoColorEmoji.ttf: "Noto Color Emoji" "Regular"
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
$ fc-match system-ui
DejaVuSans.ttf: "DejaVu Sans" "Book"

@jomority The behavior shown with Qwant is them not complying to the CSS standard by surrounding multiple font names with quotes https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#propdef-font-family
Why the quoted list of fonts would match Noto Emoji, I have no idea, as fc-match lists some other font for it:
$ fc-match "Helvetica, Arial, Noto Sans, Ubuntu"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
$ fc-match '"Helvetica, Arial, Noto Sans, Ubuntu"'
arial.ttf: "Arial" "Standard"
Comment by Chandradeep Dey (chandradeepdey) - Monday, 24 February 2020, 05:56 GMT
If he has no fonts installed that match with the given string, it should match the default sans-serif font. That could be Noto Sans for him. However, the changes in commit 4a28a114f9c5b614eac1ecbfce1fb7ab730b78ea (20191016-3) should guarantee Noto Sans is replaced by Noto Color Emoji only if the former cannot display the glyph.
@jomority could you post an fc-match of "Helvetica, Arial, Noto Sans, Ubuntu" like @rbialon did?

As for the GitLab issue, I tried uninstalling as many fonts as I could using pacman -Rddns. Still couldn't replicate your issue. Maybe try using this file that I use https://github.com/chandradeepdey/arch-config/blob/master/etc/fonts/local.conf and run fc-cache. If it does work, don't ask me how though. A week ago I believed I demystified fontconfig. Today I believe fontconfig is pure black magic.
Comment by Moritz J (jomority) - Monday, 24 February 2020, 11:25 GMT
Yes, with both versions, 20191016-1 and 20191016-3, they are the same results:

$ fc-match "Helvetica, Arial, Noto Sans, Ubuntu"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
$ fc-match '"Helvetica, Arial, Noto Sans, Ubuntu"'
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"

Maybe Firefox does something special with fontconfig. As your said: it's black magic :D

Also, I submitted a bug report to Qwant for the invalid CSS.
Comment by Antonio Rojas (arojas) - Friday, 28 February 2020, 12:10 GMT
Please test 20191016-4
Comment by Moritz J (jomority) - Friday, 28 February 2020, 13:41 GMT
This fixes my problem. Thank you <3
Comment by Raphael Bialon (rbialon) - Friday, 28 February 2020, 15:48 GMT
I can confirm that the reported behavior does not occur with 20191016-4 anymore, thank you!
Comment by Link Dupont (link) - Tuesday, 24 March 2020, 12:51 GMT
  • Field changed: Percent Complete (100% → 0%)
I am still experiencing this bug even with 20191016-4 with gitlab.com content viewed in a WebKit browser (Epiphany, though I would imagine it's true for any WebKit-based browser).

Loading...