Firefox font rendering on CJK characters totally borken in pre block
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: RungeCC, Unassigned)
References
Details
Attachments
(7 files)
2024-05-12_06-30.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
- x86_64linux: NixOS version 24.05.20240507.b211b39 (Uakari)
- Firefox version 125.0.3 (x64)
- fontconfig in /etc/fonts/conf.d/
00-nixos-cache.conf 40-nonlatin.conf 53-no-bitmaps.conf
10-hinting-full.conf 45-generic.conf 60-generic.conf
10-nixos-rendering.conf 45-latin.conf 60-latin.conf
10-scale-bitmap-fonts.conf 48-spacing.conf 65-fonts-persian.conf
10-sub-pixel-none.conf 49-sansserif.conf 65-nonlatin.conf
10-yes-antialias.conf 50-user.conf 69-unifont.conf
11-lcdfilter-default.conf 51-local.conf 80-delicious.conf
20-unhint-small-vera.conf 52-nixos-default-fonts.conf 90-synthetic.conf
30-metric-aliases.conf 53-nixos-reject-type1.conf
- all above conf files are included in /etc/fonts/fonts.conf:
<include ignore_missing="yes">/etc/fonts/conf.d</include>
- default fonts: (in 52-nixos-default-fonts.conf)
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'urn:fontconfig:fonts.dtd'>
<fontconfig>
<!-- Default fonts -->
<alias binding="same">
<family>sans-serif</family>
<prefer>
<family>Noto Sans CJK SC</family>
<family>Noto Sans</family>
</prefer>
</alias>
<alias binding="same">
<family>serif</family>
<prefer>
<family>Noto Serif CJK SC</family>
<family>Noto Serif</family>
</prefer>
</alias>
<alias binding="same">
<family>monospace</family>
<prefer>
<family>OperatorMono Nerd Font</family>
<family>Sarasa Mono SC</family>
<family>Hack</family>
<family>Noto Sans Mono</family>
</prefer>
</alias>
<alias binding="same">
<family>emoji</family>
<prefer>
<family>Noto Color Emoji</family>
</prefer>
</alias>
</fontconfig>
-
all above fonts are correctly installed
-
All extensions are disabled.
-
source code:
<html> <body> <pre>这是一些中文字符ここにいくつかの日本語の文字があります</pre> </body> </html>
Actual results:
Then (see attachment)
- Note: rendering is also broken in firefox's inspector
the second character("是") is squeezed which is abnormal.
- Note: if change 10-hinting-full.conf to 10-hinting-slight.conf then everything is ok.
Expected results:
No weird font rendering, like chromium does.
|
||
Comment 1•2 years ago
|
||
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 2•1 year ago
|
||
|
|
||
Comment 3•1 year ago
•
|
||
(In reply to RungeCC from comment #0)
fontconfig in /etc/fonts/conf.d/
[...] 10-hinting-full.conf [...]
[...]
- Note: if change 10-hinting-full.conf to 10-hinting-slight.conf then everything is ok.
For what it's worth: on Ubuntu 22.04, I have (from the default configuration) /etc/fonts/conf.d/10-hinting-slight.conf, and no files with full in the name or in their contents in the /etc/fonts/conf.d/ directory.
(Though I do have /etc/fonts/conf.avail/10-hinting-full.conf in a neighboring directory, and it looks like I can use that by symlinking it in, in place of 10-hinting-slight.conf. But even if I do that, I don't see the second character being squashed.)
Could you check what font Firefox says it's using for that run of text when you hit the bug? See bug 1850830 comment 2 for steps (1)-(4) on
how do do that. Thanks!
|
|
||
Updated•1 year ago
|
- the content of
/etc/fonts/conf.d/10-hinting-full.conf:
Note that file originally comes with<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> <fontconfig> <description>Set hintfull to hintstyle</description> <match target="pattern"> <!-- This sort of configuration is available on the major desktop environments and we don't have to break it with "assign" unconditionally. however, we want to set something for others. So we use "append" here to get this working in both cases so that most clients would takes a look at the first place only. --> <edit name="hintstyle" mode="append"><const>hintfull</const></edit> </match> </fontconfig>fontconfig(see here), slightly modified. - font used(see attachment font.png)
Sorry for link to wrong file(that hyperlink refs to 10-hinting-slight.conf), the correct one is this.
|
|
||
Comment 7•1 year ago
|
||
So it looks like the font in question is "Sarasa Mono SC", from the comment 4 screenshot.
Here's a testcase to more-explicitly request that font, if it's available. (It's not available in Ubuntu repos, but I was able to find a copy of it online for testing -- though so far I've just tested in a Win11 VM where it seems to render fine.)
|
|
||
Updated•1 year ago
|
|
|
||
Comment 8•1 year ago
|
||
Hmm, I'm so far unable to repro.
I'm using a fresh installation of Ubuntu 22.04, with Sarasa Mono SC downloaded from a link on https://en.likefont.com/font/1159191/ (not sure if it's reputable/safe or not -- hence, testing in a VM), and with your exact above-quoted fontconfig file replacing my own "slight" one, and with various font packages removed until Sarasa Mono SC is the only font that shows up as being used on testcase 2 in Firefox DevTools for me.
I'm not seeing any issue with the second character like you were. Here's a screenshot of what I get. Note that I do get a "Tofu" glyph for one of the characters 3/4 of the way through the line, but that's presumably just due to a missing character in this font, which would normally be filled in by a fallback (and I removed all of the fallback fonts that were getting triggered as noted above).
I wonder if we've got different versions of the Sarasa Mono SC font, and maybe the version that you have might have some bug in the hinting data? (just a guess)
|
|
||
Comment 9•1 year ago
|
||
(side note, I'm just noticing that both of your screenshots show a <div id="immersive-translate-popup"> in the DOM, which is not actually part of the testcase. I wonder what's adding that? It's not present for me, and I don't see "immersive-translate-popup" in Firefox's source at all, so I don't think it's something being added by our own built-in translation feature. It's probably unrelated to the rendering bug here, but it's conceivable that it might be doing something interesting.)
|
||
Comment 10•1 year ago
|
||
There are definitely different font versions involved here; notice that although the family name is the same, the fullname shown in the screenshot in comment 8 is slightly different from that in comment 4.
I haven't set up a machine with the config to try and reproduce this locally yet, but I suspect the font involved is more likely the version from https://github.com/be5invis/Sarasa-Gothic/releases. If you look in the "single family" packages there, and download the "Mono" archive, the SarasaMonoSC-Regular.ttf font has the full name "Sarasa Mono SC" (with spaces) as seen in the reporter's screenshot.
|
Reporter | |
Comment 11•1 year ago
|
||
|
|
Reporter | |
Comment 12•1 year ago
|
||
|
|
Reporter | |
Comment 13•1 year ago
|
||
(side note, I'm just noticing that both of your screenshots show a <div id="immersive-translate-popup"> in the DOM, which is not actually part of the testcase. I wonder what's adding that? It's not present for me, and I don't see "immersive-translate-popup" in Firefox's source at all, so I don't think it's something being added by our own built-in translation feature. It's probably unrelated to the rendering bug here, but it's conceivable that it might be doing something interesting.)
That's an extension, I'm sorry for forgetting to disable it. But I think it's unrelated, the issue still happens if I disable it(see firefox.png, currently all extensions are disabled).
Font "Sarasa Mono SC" is from here. It's definitely related with the issue since if I use other font such as "Noto Sans Serif SC" for example then the rendering is OK(see attachment, now font rendering only broken inside the inspector, where the firefox adopts my system setting of monospace font to be "Sarasa Mono SC"). However, chromium does not have such problem (See attachment chromium.png).
|
|
Reporter | |
Comment 14•1 year ago
|
||
(In reply to RungeCC from comment #13)
Font "Sarasa Mono SC" is from here. It's definitely related with the issue since if I use other font such as "Noto Sans Serif SC" for example then the rendering is OK(see attachment, now font rendering only broken inside the inspector, where the firefox adopts my system setting of monospace font to be "Sarasa Mono SC"). However, chromium does not have such problem (See attachment chromium.png).
This can be seen from the above conf (on default font) of fontconfig:
<alias binding="same">
<family>monospace</family>
<prefer>
<family>OperatorMono Nerd Font</family>
<family>Sarasa Mono SC</family>
<family>Hack</family>
<family>Noto Sans Mono</family>
</prefer>
</alias>
OperatorMono Nerd Font has no CJK script character, so Sarasa Mono SC will be chosen here.
|
||
Updated•1 year ago
|
|
|
||
Comment 15•1 year ago
•
|
||
Thanks for the additional clarifications.
Unfortunately I'm still unable to reproduce, using the "Single Family TTF Package" / "Mono" downloads from GitHub.
It's conceivable that the issue is specific to a particular version of the font, and the newest version (the version I'm testing) has fixed it -- I do see that on the github page that you linked, the newest release has datestamp "last week" which is more recent than when you filed this bug. Also, looking at the issues there, I see a recently-filed/fixed issue about the display of the font: https://github.com/be5invis/Sarasa-Gothic/issues/392
It mentions that the brokenness is specific to the hinted version, which makes it feel likely related to this issue.
Could you try updating to the latest release of the font and see if that fixes the issue for you?
|
|
||
Updated•1 year ago
|
|
|
||
Comment 16•1 year ago
|
||
Aha -- after installing the previous 1.0.11 version of the font, I can reproduce the issue as-screenshotted -- the second glyph in the attached testcase looks vertically-squashed, for example.
So: this does indeed seem to have been a bug with that specific font version, and almost certainly https://github.com/be5invis/Sarasa-Gothic/issues/392 , and it's not reproducible with the newer 1.0.12 font version -- so the best course of action is to install the updated version of that font.
Resolving as "invalid" since this turned out to be a bug in the font rather than a bug in Firefox.
Description
•