Can't load font using local()

[metapone]

Running from the default terminal on Windows 10, if I, after installing a custom font like Google's Noto Sans JP, use this CSS in my HTML:
@font-face{ font-family: "Noto Sans JP"; src: local("Noto Sans JP") }
WeasyPrint will throw a "WARNING: Font-face "Noto Sans JP" cannot be loaded.", and if there are a large number of CJK characters, produce a PDF with mojibake like these:

If I reduce the amount of CJK characters enough, the PDF will be rendered okay, but with the default system font (Meiryo).

But if I put url() instead of local() and update my CSS to:
@font-face{ font-family: "Noto Sans JP"; src: url("NotoSansJP-Regular.otf") }
Then the HTML is rendered as it should be, with the custom font.

[liZe]

Hello!

I can reproduce your problem. Actually, these fonts have their font weights in their fullnames (that WeasyPrint uses to solve local() fonts, and that’s logical because you want to target a font, not a font family). Using "Noto Sans JP Medium" works.

[metapone]

The Noto Sans JP Regular font name is just "Noto Sans JP" (no "Regular") or at least that what the file's Property dialog told me, so shouldn't my example work then?
And I'll try "Noto Sans JP Medium" tomorrow to see if WeasyPrint would pick up the file NotoSansJP-Medium.otf, thanks.

[liZe]

The Noto Sans JP Regular font name is just "Noto Sans JP" (no "Regular") or at least that what the file's Property dialog told me, so shouldn't my example work then?

That’s also what my font viewer also says, but this name is the font family. The full name used by Fontconfig is the family name + weight + style + …, so that you can precisely choose the font you need.

We could be nicer and have fallbacks for local(), and other browsers may do this, but that would cause other problems (like randomly choosing a font weight when you don’t define one). Keeping the current behavior forces users to choose the font instead of just defining a family name, and that’s probably better this way.

And I'll try "Noto Sans JP Medium" tomorrow to see if WeasyPrint would pick up the file NotoSansJP-Medium.otf, thanks.

It does work for me, I hope that it will work for you too 🤞.

[metapone]

Bad news: local("Noto Sans JP Medium") didn't work. Maybe there's something wrong with my Windows or the font? I downloaded them from here (click the Download family), did you get that same file or from somewhere else?
url("NotoSansJP-Medium.otf") still works so I could use that as a crutch, but every font file imported when exporting PDF, even by the font-face that isn't used, add ~5 seconds to the whole process so I'd rather find another work around...

---

After a bunch of testing, here're some of my observation:

• local() works on my CentOS machine, but not Windows
• local() won't work if the name of the font-family is the same as an installed font family. In my case, if I installed Noto Sans JP and create a font-face with font-family "Noto Sans JP" also, but with the source pointing to local("Noto Sans JP Bold") for example, the result with be Noto Sans JP Regular, not Bold. Changing the name to "Noto Sans JP Custom" make WeasyPrint use Bold, so there's that.

So apparently it has something to do with my Windows, but I don't know where to go from here.

[liZe]

I downloaded them from here (click the Download family), did you get that same file or from somewhere else?

That’s where I got the font too.

But… Well, it’s actually useless to only use local() in a @font-face rule, because using font-family: Noto Sans JP should just work if the font is installed. local() is only useful as the first element of a list of URLs, to avoid the download. So, without the @font-face rule, you should be able to use the font if it’s installed correctly.

So apparently it has something to do with my Windows, but I don't know where to go from here.

It probably means that the font is not installed correctly. How did you install the font?

but every font file imported when exporting PDF, even by the font-face that isn't used, add ~5 seconds to the whole process

Adding fonts in the PDF can take some time, but 5 seconds seems to be a little bit too long. Which version of WeasyPrint do you use?

[metapone]

Version 52.4. Times taken before: 5s. Times taken after adding 7 font-face: 34s.
About the fonts, Ctrl+A => Right click => Install. The usual way.
And WeasyPrint loads fonts at declaration, not when they are used like browsers do right? Could be a neat optimization if implemented.

[metapone]

Experiment today on Windows with font-family only, no font-face. Use a pre-installed font on Windows, Yu Gothic:

• font-family: "Yu Gothic": Latin displayed as Yu Gothic, Japanese as gibberish like the opening post's sample.
• font-family: "Yu Gothic Regular": Latin displayed as the default system font (Meiryo?), Japanese as gibberish. Probably because Yu Gothic Regular isn't actually named Yu Gothic Regular, but I don't know how to get the name that WeasyPrint used and so had to guess. Do you know how to do that on Windows?

Even a custom font-face pointing to local("Yu Gothic") doesn't work on Windows.

[liZe]

(Not a direct answer, but to be clear:

• in "font-family" you should use the font family name, ie. "Yu Gothic" in your case,
• in "local()" you should use the font name, ie. "Yu Gothic Regular" in your case.)

• font-family: "Yu Gothic": Latin displayed as Yu Gothic, Japanese as gibberish like the opening post's sample.

That’s strange. Could you please share your HTML+CSS sample, and the corresponding PDF files?

• font-family: "Yu Gothic Regular": Latin displayed as the default system font (Meiryo?)

That’s normal (see above).

Even a custom font-face pointing to local("Yu Gothic") doesn't work on Windows.

That’s normal too (see above).

[metapone]

Sorry for being so late. I've created a sample HTML file that has the same problem and sent it to your email, guillaume@courtbouillon.org. Since I've remove almost every CSS rule and HTML layout possible, my current guess is that the problem has something to do with the amount of characters WeasyPrint has to draw. If I cut short the amount of different characters in the sample file, or instead of using multiple characters just repeating a few lines for the same amount of characters, the problem would not occur.
One more thing is that the corrupted file is displayed differently when viewing from different tools. Here's how it is viewed in SumatraPDF, a FOSS PDF viewer. Every Japanese kana is displayed as gibberish Latin characters in another font, possible Times New Roman while the Latin characters are displayed correctly in Yu Gothic:

The same file viewed from Chrome on Windows. The gibberish Latin characters are smashed together and displayed in square boxes:

[liZe]

I should have checked the PDF as soon as this issue was reported!

The bug you have is actually a duplicate of #1292, that just randomly breaks fonts included in PDF documents 😒. Using a previous version of Cairo will fix your problem (until Cairo releases a new version including the fix).

[metapone]

How you tell me how to downgrade Cairo on CentOS and Windows (I have 2 separate environments)? I'm not familiar with Yum, and on Windows Cairo comes with the GTK+ package so I'm not sure whether to find an older version of libcairo-2.dll (?) or GTK+.

[liZe]

On CentOS, I think that the fix has been packported into the cairo-1.17.4-3 package. Updating to this latest version will fix the problem.

On Windows, you can use a previous version of GTK+. Version 2020-11-22 includes Cairo 1.17.2 that doesn’t have this bug.

[metapone]

Thanks liZe, characters are now not corrupted randomly anymore!
That just leave my first problem on Windows 10:

• font-family: "Noto Sans JP"; doesn't work
• font-family: "Noto Sans JP Regular"; doesn't work
• @font-face { src: local("Noto Sans JP"); } doesn't work
• @font-face { src: local("Noto Sans JP Regular"); } doesn't work

[liZe]

These two should work, because that’s the common use case:

• font-family: "Noto Sans JP"
• @font-face { src: local("Noto Sans JP Regular") }

This one should work too because of fuzzy matching:

• font-family: "Noto Sans JP Regular"

This one may not work, by design:

• @font-face { src: local("Noto Sans JP") }

If the first ones don’t work, it means that Fontconfig can’t find the installed font.

Where is your font installed? If it is in ~/AppData/Local/Microsoft/Windows/Fonts (~ being your home folder), then we may have a solution here: NatronGitHub/Natron@5758f2d

[metapone]

Sadly, it's in the usual place, C:\Windows\Font.

[liZe]

Sadly, it's in the usual place, C:\Windows\Font.

Then I really don’t know what’s wrong.

Could you please try to launch fc-match.exe "Noto Sans JP" in a terminal? This tool is installed with GTK and should give you which font matches the pattern. It also has a -v option to get extra information, but I’m not sure about how to give this argument on Windows (-v, /v ?).

[metapone]

Doesn't look like it recognize Noto Sans JP or Noto Sans JP Regular.

Now, I'll have to apologize to you because of my inadequate understanding. The font is in fact installed in ~/AppData/Local/Microsoft/Windows/Fonts. In my defense, Windows also misled me with its presentation. Here's what happened when I opened C:\Windows\Fonts earlier on Explorer:

Noto Sans JP was there, right?

Not according to dir (cmd's equivalent of ls):

[liZe]

Noto Sans JP was there, right?

Not according to dir

Oh. These interfaces can really be misleading…

So, it means that we actually have the same problem as NatronGitHub/Natron@5758f2d. You can try to add <dir>~/AppData/Local/Microsoft/Windows/Fonts</dir> below <dir>WINDOWSFONTDIR</dir> in etc/fonts/fonts.conf (where GTK is installed). It should work as a workaround.

If it works, we can open a new issue for tschoonj/GTK-for-Windows-Runtime-Environment-Installer, asking them to include the same fix as NatronGitHub/Natron@5758f2d.

[metapone]

Thanks, your suggestion works perfectly! As noted in fonts.conf tho people shouldn't edit that file since updates will override it, so I put <dir>~/AppData/Local/Microsoft/Windows/Fonts</dir> in etc\fonts\conf.d\51-local.conf instead and it works immediately.
I'm not familiar with the GTK installer so I'll have to leave the issue creation to you, is that okay?
And if there are any other info you need I'll try to answer it, else you can close this bug.

[liZe]

Thanks, your suggestion works perfectly! As noted in fonts.conf tho people shouldn't edit that file since updates will override it

Of course, that was just a workaround to test.

so I put <dir>~/AppData/Local/Microsoft/Windows/Fonts</dir> in etc\fonts\conf.d\51-local.conf instead and it works immediately.

👍🏽

I'm not familiar with the GTK installer so I'll have to leave the issue creation to you, is that okay?

Hmmm… After some time spent on GitHub, I now think that it’s a bug in Fontconfig. And actually, it’s already reported: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/144. I’ve added a comment.

And if there are any other info you need I'll try to answer it, else you can close this bug.

Done!