1941820 - Noto Sans woff2 font is rendered in italic style

Status: VERIFIED FIXED

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

Description

[joshas]

Attachment: Screenshot 2025-01-15 at 17-49-51 Developer.png

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

Steps to reproduce:

Visit https://develop.kde.org/

Actual results:

All fonts on websites are in italic style.

Expected results:

Website should be rendered using Noto Sans Regular font.

Direct link to font used: https://develop.kde.org/fonts/noto-sans.woff2
Trying to check "Response" in network tools for this asset ends up with error message: "Font preview could not be generated".

Comment 1

[joshas]

Did a regression search with mozregression and here is the result:
INFO: Last good revision: cbd6a4e86db48aef29684602041908cb2debef2f
INFO: First bad revision: 030412276e15ccc3c1893524e87b3b1b822e91fa
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cbd6a4e86db48aef29684602041908cb2debef2f&tochange=030412276e15ccc3c1893524e87b3b1b822e91fa

Comment 2

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

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

Comment 3

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

:jfkthame, since you are the author of the regressor, bug 1928458, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I can't reproduce this with the noto fonts installed and uninstalled from my machine.

There's a warning in the console:

downloadable font: Layout: tags aren't arranged alphabetically. (font-family: "Noto Sans" style:normal weight:400 stretch:100 src index:2) source: https://develop.kde.org/fonts/noto-sans.woff2

The relevant font-face is:

@font-face {
  font-family:'Noto Sans';
  font-style:normal;
  font-weight:400;
  font-display:swap;
  src:local("Noto Sans"),
  local("NotoSans"),
  url("/fonts/noto-sans.woff2") format("woff2"),
  url("/fonts/noto-sans.woff") format("woff")
}

So it seems we might be picking an italic font from your system... Reporter:

• What distro / etc are you on?
• What does fc-match NotoSans output on a terminal? What about fc-match "Noto Sans"?
• Do you have noto sans installed? Does uninstalling it fix the rendering? If so, can you link to the relevant package / etc to see what might be going on?

Thanks. Triaging as S3 for now assuming this is due to an uncommon configuration, but if it's not we might bump it.

Comment 5

[joshas]

What distro / etc are you on?
Same issue on Fedora Linux 41 (Workstation Edition) GNOME, and KDE spin.

What does fc-match NotoSans output on a terminal?
NotoSans-Regular.ttf: "Noto Sans" "Regular"

What about fc-match "Noto Sans"?
NotoSans-Regular.ttf: "Noto Sans" "Regular"

Do you have noto sans installed?
Yes

Does uninstalling it fix the rendering?
Cannot uninstall NotoSans fonts on KDE, as desktop environment depends on them. But tried disabling them. Fallback font "Nimbus" is used instead, no more italic variant though. Enabling fonts returned to initial issue with italic fonts. Clearly something is up with local fonts. Going to try different distro a bit later.

If so, can you link to the relevant package / etc to see what might be going on?
n/a

Comment 6

[joshas]

No issues on Linux Mint 22.1, everything points to some issue with Fedora. I should probably move this to Fedora bug tracker?

Comment 7

[Pongpeera Wongprasitthiporn]

(In reply to joshas from comment #6)

No issues on Linux Mint 22.1, everything points to some issue with Fedora. I should probably move this to Fedora bug tracker?

I'm having the same problem on Linux Mint 22.1, Firefox 134.0.2 packaged by Linux Mint. This is how I reproduced it:

1. Install GNOME UI font (which is built off Inter Variable) as TTF locally (https://gitlab.gnome.org/GNOME/adwaita-fonts; it is now renamed to Adwaita Sans though)
2. Open my website at https://www.techtransthai.org, which the website itself serves woff2 file of GNOME UI font and the css contains this:

font-family: "GNOME UI", "Noto Sans Thai Looped", Inter, system-ui, Avenir, Helvetica, Arial, sans-serif;

3. Notice the font being rendered in italics

fc-match "GNOME UI" returns

GNOMEUI.ttf: "GNOME UI" "regular"

After deleting the local GNOMEUI.ttf file and restarting Firefox, it now renders correctly and not in italics.

Also, as of now (23 Jan 2025, 19:00 GMT+7) looks like KDE Developer website switched fonts to Inter, as seen by WhatFont's output:

"Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";

Comment 8

[joshas]

https://api.kde.org/ is still on older version of documentation theme where NotoSans issue can be observed and debugged.

Comment 9

[Jonathan Kew [:jfkthame]]

What does fc-match -v "Noto Sans:Italic" report on your Fedora machine where this issue occurs? I'm suspecting there must be something a little odd about how the locally-installed font is configured.

Comment 10

[joshas]

Attachment: Output of fc-match

Here's the output of 

```

Comment 11

[Jonathan Kew [:jfkthame]]

Thanks - looks like it's a slightly different version than I have on Ubuntu, but I don't see anything that looks surprising/wrong there. Just for comparison, could you also provide the output of fc-match "Noto Sans:Regular" (though I suspect it'll look equally innocent...)

Maybe I can get a VM set up with fedora and see if that'll reproduce it for me. Currently mystified as to what's going wrong here.

Comment 12

[joshas]

Attachment: fc-match -v "Noto Sans:Regular"

Thank you for taking interest. Here's the output for "Regular".

Comment 13

[Jonathan Kew [:jfkthame]]

Thanks - again, looks perfectly normal and (sadly) doesn't give me any clue what's happening. I'll try to get a fedora instance going here, as it'll be easier to investigate if I have hands-on access.

Comment 14

[Jonathan Kew [:jfkthame]]

I installed Fedora 41 in a virtual machine, but I'm still not seeing this issue.

One thing I do notice, though, is that my Fedora 41 is using the variable-font version of Noto Sans, with .ttf files installed in /usr/share/fonts/google-noto-vf/, whereas yours appears to have the non-VF release, with the files in /usr/share/fonts/google-noto/. So I've ended up with a different configuration than you are using, and in particular, an entirely separate collection of Noto Sans font resources.

I just did a default install using the "Fedora Workstation 41 Live ISO" image (Intel and AMD x86_64 version) available from https://fedoraproject.org/workstation/download, and this is what I got. Do you know what I'd need to change to get a configuration more like yours? Have you added or removed packages related to fonts that may have changed which resources you have installed?

Comment 15

[Jonathan Kew [:jfkthame]]

Oh, wait -- I just realized that the version of Firefox on my Fedora setup is old. I'll install an up-to-date release and try again....

Comment 16

[Jonathan Kew [:jfkthame]]

Aha! With a newly-downloaded Firefox 134, I can now reproduce the problem: the https://api.kde.org/ site appears in (unwanted) italics. Great!

Now to try and figure out why....

Comment 17

[Jonathan Kew [:jfkthame]]

I think I see what's happening here, at least on my Fedora 14 setup.

The variable-font version of Noto Sans comes as two resources, one for the regular style (with variable weight), and one for the italic style (again, with variable weight). Each of these in turn defines a number of "named instances" for specific weights (regular, medium, semibold, bold). Each of these has a unique full-name (e.g. Noto Sans Bold Italic) and postscript name (e.g. NotoSansItalic_700wght) by which it can be looked up using src: local(...) in a @font-face rule. These are all exposed as separate FcPatterns in the font set that fontconfig gives us.

However, there's also an FcPattern representing the variable-font resource as a whole, with its full range of weights. This does not have a concrete full-name or psname, and when these are missing from the pattern, we attempt to synthesize a full-name so that the font could still be looked up. We do that by concatenating the family and style names. But these have no style name either. And so we end up with a "full-name" of just "Noto Sans", and this happens for both the upright and italic Noto Sans variable-font resources. So we've got two entries with the same "full-name" identifier, and which one you get will be essentially arbitrary.

To fix this, we should simply avoid including such variable-font patterns in the candidates for src: local() lookup. As that is supposed to reference an individual font face (not a family or a collection of faces), it's logical that variable resources should be excluded (only their named instances, AKA specific faces, will be available to look up).

@joshas, I think this means, if my understanding is correct, that you must have the variable-font version of Noto Sans installed as well as the non-variable .ttf files that your fc-match output is reporting. Only the variable-font version is liable to run into this issue, because of how the two resources are packaged. If you check in /usr/share/fonts/, am I right in suspecting you'll find a google-noto-vf directory in addition to the google-noto one, and that'll have the variable-weight Noto Sans resources in it?

Comment 18

[Jonathan Kew [:jfkthame]]

As an aside, this also highlights that the @font-face rule I see on that https://api.kde.org/ site is poorly written. It has:

@font-face {
  font-family:Noto Sans;
  font-style:normal;
  font-weight:400;
  font-display:swap;
  src:local("Noto Sans"),
  local("NotoSans"),
  url(/aether-devel/fonts/noto-sans..woff2) format("woff2"),
  url(/aether-devel/fonts/noto-sans..woff) format("woff")
}

which is clearly intended to use a local copy of Noto Sans if present, and fall back to downloading a resource if not.

However, neither "Noto Sans" nor "NotoSans" are correct local names, because src: local(...) accepts Postscript or Full face names, and the actual names would be "Noto Sans Regular" (fullname) or "NotoSans-Regular" (psname). It does not match on Family names, which is what "Noto Sans" is. So the attempt to look up a local face should always fail.

(In practice, some browsers may actually match family names in src:local(...), but that's a violation of the CSS Fonts spec, and bugs have been filed against them....)

In our case, it is picking up a local variable-weight resource, because we (incorrectly) treat it has having the fullname "Noto Sans", but we'll fix that here. But to achieve its intended purpose, the rule should be modified to use the proper psname and fullname of the desired face.

Comment 19

[joshas]

Thank you for taking time to do thorough investigation and for detailed explanation. The part about declaring local font names is very useful. I always assumed that webfont and local font names are identical.

And yes, you are right, I have both, google-noto and google-noto-vf directories.

Comment 20

[Jonathan Kew [:jfkthame]]

Thanks for confirming that.

(I'm re-opening this issue, as our current behavior with the variable-font resources is wrong; I'm about to post a patch here to fix it.)

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1941820 - Don't allow src:local() lookups on Linux to find fontconfig patterns representing variable fonts, except for concrete named instances.

Comment 22

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

Set release status flags based on info from the regressing bug 1928458

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1941820 - Don't allow src:local() lookups on Linux to find fontconfig patterns representing variable fonts, except for concrete named instances.

Original Revision: https://phabricator.services.mozilla.com/D235460

Comment 24

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: some users on Linux may get incorrect fonts (e.g. spurious italic)
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On a Fedora 14 desktop system visit https://api.kde.org/. The content should not be in italics.
• Risk associated with taking this patch: low
• Explanation of risk level: adds a simple check to exclude fontconfig patterns that we shouldn't be using for @font-face lookup
• String changes made/needed: none
• Is Android affected?: no

Comment 25

[Jonathan Kew [:jfkthame]]

With the Noto fonts being widely installed these days, and the variable-weight version supplanting the older discrete-weights version, this is likely to affect an increasing number of users, and the fix to avoid the issue is straightforward/low-risk, so I think we should uplift to 135 if possible.

(The fix has been tested locally, but verification once it is in the Nightly build would be appreciated.)

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cd9d5dae85d3
Don't allow src:local() lookups on Linux to find fontconfig patterns representing variable fonts, except for concrete named instances. r=dholbert

Comment 27

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/cd9d5dae85d3

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/79d3c281c455

Comment 30

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 135.0b9 on Fedora 41 VM. https://api.kde.org/ page will have content in italics.
The issue is verified fixed with Firefox 136.0a1 (2025-01-27) and 135.0b10 (20250125140751 - comment 28) on Fedora 41 VM. https://api.kde.org/ page content is no longer in italics.