On OSX servo shows CJK chars as squares

[bobchao]

<ul>
  <li>C 中文</li>
  <li>J 日本語</li>
  <li>K 한국어</li>
</ul>

[bobchao]

On Linux it works well (humm, not that "well" on the layout part but at least it shows the chars correctly)

[frewsxcv]

Possibly related to #7762

[hiroshiyui]

I can reproduce such square (or so-called "tofu") font issue on my system, which runs:

• Arch Linux x86-64, Linux kernel 4.4.5
• KDE Plasma 5.5.5
• Servo (built from the latest source code on Git)

Just found that if I change my fonts fallback order in Fontconfig, to set the first candidate font from "Noto Sans" to "Noto Sans CJK TC", then almost all CJK characters are shown as expected.

[Artoria2e5]

This problem is in a form somehow like this libgdiplus bug (well, in the "Sans" case), where libgdiplus didn't consider any possible extra fontconfig substitutes and only used the first match. Some system-based fallback is necessary…

As a temporary hack, perhaps last_resort_font_families() can be set according to glyph coverage instead? It looks like OS X users can try stealing Arial Unicode MS from Windows for now, but there's nothing except for font name hacks for FreeType users.

Some extra generalized test cases:

• try to show emojis using sans-serif with Noto Emoji installed and available in fc-match -a "sans-serif" | grep Emoji
• use any other rare scripts (e.g. Powerline PUA symbols) that requires a not-specified-in-CSS on-system fallback font.

#7762 and #9479 sound more like webfont failures. (And GitHub has switched to SVG icons.)

[mmatyas]

Does not work for me either, on Xubuntu nor GNOME, 15.10:

[Artoria2e5]

@mmatyas If you are reporting such cases on LInux, mentioning the output of fc-match Sans can help confirm @hiroshiyui's report (and my guess).

[mmatyas]

fc-match Sans returns DejaVuSans.ttf: "DejaVu Sans" "Book" for me.
Here's the full output of fc-match -a "sans-serif": http://pastebin.com/afMmsaUT, hope this helps.

[saschanaz]

CJK also is being displayed as squares on Windows nightly build. Should I open a new issue for Windows build?

[nox]

The characters are displayed correctly on macOS.

[mmatyas]

Still failing on Ubuntu 16.04 and also on Solus 3 as of 2017-10-01, using the 64bit Linux build from servo.org

[Artoria2e5]

Probably nox's working report is caused by ja.wp somehow making a Japanese font the first (and only, for now) option. Make some other test cases to reopen it I guess?

[jdm]

Yeah, some links to reproduce the problem would be great.

[tigercosmos]

@jdm I think Labels should also add Linux. (#19228)

[jdm]

I've tested some of the earlier examples on macOS and they appear to render correctly. Please file new issues with testcases or links to sites that do not non-english characters correctly.