Avoid CJK legacy fonts in Windows

[ghost]

As metioned in #84035, the default serif CJK font in Windows is meh-looking.
To avoid this, we should use sans-serif font or provide CJK glyph supported font in rustdoc.css.

[rust-highfive]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ollie27 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[the8472]

This would also affect fallback for all non-CJK text and I assume serif was chosen intentionally.
Wouldn't it be better to define a custom @font-family with
src: local(sans-serif) that is scoped to CJK-specific unicode ranges or something like that?

[ghost]

@the8472 I tried to impl that like

@font-face {
font-family: 'CJK';
src: local(sans-serif);
unicode-range: U+4E00-9FFF;
}
body {
font: 16px/1.4 "Source Serif Pro", "CJK", serif;
}

but neither src: local(sans-serif) nor src: sans-serif works.

Unknown descriptor ‘src: local(sans-serif);’ in @font-face rule. Skipped to next declaration.

Unknown descriptor ‘sans-serif’ in @font-face rule. Skipped to next declaration.

[ghost]

Adding Windows CJK sans-serif fonts to font-family manually can also solve this problem.

[the8472]

Ah too bad, you're right this can't work. The spec says

Just as an @font-face rule specifies the characteristics of a single font within a family, the unique name used with local() specifies a single font, not an entire font family.

---

Adding Windows CJK sans-serif fonts to font-family manually can also solve this problem.

Depending on which unicode ranges those fonts cover they might suffer from a similar problem as switching the fallback. But with specific fonts the unicode-range approach might work.

[ghost]

Does adding a Windows font to font-family cause a license problem? I'm not sure about this.

[workingjubilee]

That sounds implausible, as long as we are not distributing it. The software is licensed to installers like Microsoft for distribution to installees, and the browser is the one "using" the font, not us. Rather, we are merely giving an ignorable direction to use something if it is convenient: the browser could ignore this direction due to license concerns if it saw fit.

But if it was a license violation, the existing use of Arial would be a license violation also, and I am not aware of anyone trying to sue what must be half of the entire English-speaking internet for mentioning Arial in their CSS "without a license".

[ghost]

Could someone add T-rustdoc label?

[GuillaumeGomez]

r? @GuillaumeGomez

[GuillaumeGomez]

Can you add screenshots to show us the comparison (before/after) please?

[ghost]

Comparison between serif and sans-serif in Windows

before 100% (batang.ttc):

after 100% (malgun.ttf):

before 140% (batang.ttc):

after 140% (malgun.ttf):

before 150% (batang.ttc):

after 150% (malgun.ttf):

[GuillaumeGomez]

I guess it's fine; Just to be sure: cc @jsha

[jsha]

I don't think this is the right solution. I think we should do the alternate thing @ghost proposes:

or provide CJK glyph supported font in rustdoc.css.

We discussed that a bit over in #84035 (comment). As @ghost pointed out, the overall Noto Sans CJK is only available in OpenType, and it's too big (20MB). So I think we should add a stanza particularly for Noto Sans KR, and ship the font. Separately, somebody should check if the default JP, SC, TC, fonts have a similar problem, and we can apply a similar fix if so.

My reasoning for preferring this approach: The fallback font is displayed while the custom font is loading. For English text, this change would mean showing a sans-serif font, and then replacing it with "Source Serif 4", which would result in more of a visual shift.

Shipping the nice font that we want to use for Korean is consistent with the approach we use for English text: we want to make sure the docs people have taken the time to write are displayed in a consistent, beautiful font. And also it's hard know what the default fallback fonts are on various different systems, which makes it hard to select a set of fallbacks that is good for all systems and all languages.

[workingjubilee]

Can we fallback to system sans serif on KR specifically?

I believe that such would be the appropriate minimal PR.
I should note that based on my experience with JP<->EN localization, I saw serif and sans serif in roughly equal proportions, but it was not on browser tech so I can't say for sure if the web platform we use changes anything.

[jsha]

This latest seems like a good approach to me! One question: Why does Malgun Gothic need a unicode-range property while Yu Gothic does not?

[ghost]

This latest seems like a good approach to me! One question: Why does Malgun Gothic need a unicode-range property while Yu Gothic does not?

Even Chinese characters with the same code might have different shapes depending on the font for each language (CN, JP, ...). So I decided to apply it only to Korean.

Can we fallback to system sans serif on KR specifically?

I've tried to implementing that, but since unicode-range with local font is seems to be ignored it may affect other language fonts. so I'm gonna just add Noto Sans KR font.

[jsha]

Can you indicate the origin and license of the font file in the commit message? And if the license requires that a license notice be distributed alongside, commit that as well.

[ghost]

https://fonts.google.com/attribution

[jsha]

Thanks! There's also a slightly unintuitive thing: The various static files are bundled into the rustdoc binary at compile time (src/librustdoc/html/static_files.rs) and written to the target directory at run time (src/librustdoc/html/render/write_shared.rs). We need to also add the license file in those places.

[jsha]

This looks good to me. I'll take some time for others to weigh in before giving an r+, and would like to do some testing later this weekend. Thanks for your work on it.

[workingjubilee]

There are at least two major ways to render Chinese characters for Chinese alone (often given as zh-CN and zh-TW).

I've tried to implementing that, but since unicode-range with local font is seems to be ignored it may affect other language fonts. so I'm gonna just add Noto Sans KR font.

Alas. That seems weird, but this is probably for the best then.

[ghost]

Could someone approve the workflow?

[GuillaumeGomez]

I'll let @jsha handle it considering he's the expert here.

r? @jsha

[jsha]

Tested this and it looks good to me! I confirmed Noto Sans KR is correctly applied on pages with Korean characters, and is not loaded on pages that don't have Korean characters. Thanks so much for implementing, @ghost

@bors r+

[bors]

📌 Commit 8a2d663 has been approved by jsha