Log in / Register

Forum › Bugs

Bold font is not selected by the Windows build

yyang
This issue is noticed during my test of the new features of build 20230306. With the attached HTML file, the Windows build fails to select the Bold version of HONOR Sans CN (a free Chinese font released at the end of last year); the Regular version is embedded instead.

The Linux version on Ubuntu 22.04 works fine. And on the same Windows machine, the Linux version running inside WSL Ubuntu 22.04 also works fine (with C:\Windows\Fonts linked to ~/.fonts).

Other Chinese fonts I've tested don't have this problem, e.g. Microsoft Yahei, HarmonyOS Sans SC, and Source Han Sans SC. (By the way, for CJK glyphs, HONOR Sans CN can be used as a drop-in replacement of the non-free Microsoft Yahei font; they originate from the same designer and the same vendor company.)

For convenience the HONOR Sans CN font files are shared here.
  1. hello.html‎ 0.5 kB
mikeday
Thanks, we will investigate this issue.
adrianwong
Hi yyang,

I've inspected the Bold version of HONOR Sans CN, and what I've been able to find is that its Windows-specific metadata specifies the font's family as "HONOR Sans CN Bold" instead of just "HONOR Sans CN". It appears that Prince is unable to find the Bold variant as a result.

Using your example, if you were to instead do something like:
<body>
    <h1 style="font-family: 'HONOR Sans CN Bold'">你好，世界！</h1>
    <h1 style="font-family: 'HONOR Sans CN'; font-weight: normal">你好，世界！</h1>
</body>

you will notice that both Regular and Bold versions are correctly embedded in the output PDF.

I am able to reproduce this issue with Prince 14, so clearly this issue isn't new. Chrome and Firefox are capable of finding the Bold version of the font despite the name difference, so I imagine we'll eventually have to figure out how to do the same.
yyang
Thank you very much for the clear answer! Fonts can be naughty indeed.
yyang
Hi, I checked the HONORSansCN-Bold.ttf font file again with a viewer (actually a plugin of Total Commander), and found there were separate fields of "Preferred Family (Windows only)" and "Preferred Subfamily (Windows only)":



I'm not a font expert, but is it possible to use that as a hint or something? Thanks again.
adrianwong
Hi yyang,

Thanks, we also came across these two fields during our original investigation. What we found was that the Windows API that Prince uses unfortunately never returns this metadata.

We've discussed investigating what the browsers do in this circumstance, and eventually implementing that in Prince.
yyang
Hello adrianwong, thanks a lot for your answer! Since I've been bugged by this issue for a long time, I did a little more digging a moment ago, and here is what I found.

First, it seems the handling of font names is not performed (or worked around) by web browsers, but by Windows itself. In the Fonts listing on my Windows computer, the 9 font files of HONOR Sans CN are grouped into a single folder.

Update: Sorry, the previous paragraph is not quite correct. Windows does group fonts nicely, but a program may need roughly the same work by itself.

These 2 Zhihu answers (both in Chinese) helped me a lot in the digging. If you happen to read Chinese, you may find them useful, too [1][2]. In short, the Preferred Family and the Preferred Subfamily fields in the Naming table are indeeded preferred by Windows to sort font files.

There is a tiny open source program otfinfo that extracts these fields nicely. On my computer, the output of "otfinfo --info HONORSansCN-Bold.ttf" is:

Family: HONOR Sans CN Bold
Subfamily: Regular
Full name: HONOR Sans CN Bold
PostScript name: HONORSansCN-Bold
Preferred family: HONOR Sans CN
Preferred subfamily: Bold
...

Its source code (mainly otfinfo.cc and otfname.cc) indicates these fields are parsed from the font data, not retrieved using Windows APIs.

Edited by yyang

yyang
Hello, it seems this issue is fixed with Prince 20240704 and HONOR Sans CN v1.04. Thanks a lot!