Select the right font depending on language

[pulkomandy]

See #6194.

The default font in HAiku is currently DejaVu Sans, which works well for latin charset family. However, it does not include Japanese nor Chinese characters.

We have VL Gothic for Japanese and WenQuanYi Microhei for Chinese. Both of them only provide a regular style, no bold, no italics. Their latin set doesn't look very nice, either, so we'd rather not use them as the default font for everyone.

Moreover, the same character (defined by a single Unicode codepoint) needs to be rendered as different glyphs when writing Japanese or Chinese. This means a single font can't make everyone happy, and the font needs to be selected depending on the language.

This could be done in ReadOnlyBootPrompt, when selecting a locale. It should either change the default font (as seen in the font preflet), or the fallback font (currently hardcoded in app_server font rendering). We need a way to map languages to fonts, as there may be other languages displayed (eg in web pages). This would allow mixing Japanese and Chinese in the same text document.

Dano had these settings in the font preferences. But of course, no configuration at all is better.

[scottmc]

Here's a link to fontconfig, which may be just the thing to use for this:
​http://www.freedesktop.org/wiki/Software/fontconfig
Note bullet point 3: identify the set of fonts required to completely cover a set of languages. With fontconfig-2.10.0 we have finally gotten fontconfig to build cleanly on Haiku and there is now a working .bep file for it on Haikuports.

[pulkomandy]

The app_server now uses fontconfig to implement BFont::Blocks, which means we can go through the list of fonts and find one which matches the language. However, for this we need to map languages to the required unicode blocks. Then, we need to: 1) Have the boot prompt app itself change its own font to render the language properly 2) Set up the system font accordingly when exiting, so other apps also use that font.

[axeld]

Is the language problem common outside of CJK? In any case, the system font doesn't need to change at all. Let the user choose the system font. Just choose a different font to provide glyphs not found in the chosen font. Since the default system font should only cover latin, that way the problem can be solved within the app_server.

The applications should be able to communicate a language to the app_server, though, in order to override defaults. For example, even when the system is set to French, Web+ could render a Korean site in that language's preferred font if Web+ shares its knowledge about the language of the site. And BootPrompt would work in the same way; it would change its language, and tell the app_server about it.

[pulkomandy]

CJK has the additionnal problem that even if you know which blocks from the font you need, you can't tell wether the glyphs in there are drawn the appropriate way for each language. I'm not sure how fontconfig handles this, but it should be possible as well.

Anyway, the idea for the ReadOnlyBootPrompt is to perform the initial system setup so the application that run as part of the install process (Installer, DriveSetup) or the desktop, if you decide to start it, looks correct and you don't have to reach the preference panels to configure things yourself. This is why it should set the system font to one which can render the selected language (in the same way it sets the locale preferences and the keyboard layout already).

The "font overlay" to replace missing glyphs with ones from another font is nice as a fallback, but it means the user has little control on how the font looks. If most of the text on display is in Japanese, it then looks like changing the (latin-only) system font has no effect at all on the rendered text.

For other cases, I agree there should be a way to query the interface kit for a font suitable for a given language.

[tidux]

One thing Linux gets right - dynamic font fallback is done on a per glyph basis. This is important for things like representing emoji and CJK characters mixed in with, say, fixed-width ASCII. This turns out to be a very important use case for boosting adoption, because a large part of the open source OS enthusiast community are anime and manga fans from the West (Americas, Europe). There are many places in that community where you might encounter English, Spanish, Portuguese, French, Japanese, and high-Unicode art glyph text all on the same web page or within minutes of each other on the same IRC channel. There's no way to pick the right fonts for glyph coverage ahead of time unless you go with GNU Unifont or another vaguely-correct catch all font. The Noto (No Tofu - glyph-not-found boxes are often called "tofu") fonts are a good step in the right direction, but they are a bit limited.

The "font overlay" to replace missing glyphs with ones from another font is nice as a fallback, but it means the user has little control on how the font looks. If most of the text on display is in Japanese, it then looks like changing the (latin-only) system font has no effect at all on the rendered text.

This is true, but it's still superior to text not rendering at all. Make it render, then worry about appearance later.