Opened 8 years ago

Last modified 22 months ago

#7961 new bug

Select the right font depending on language

Reported by: pulkomandy Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Kits/Locale Kit Version: R1/Development
Keywords: Cc:
Blocked By: #7816 Blocking: #6967
Has a Patch: no Platform: All

Description

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.

Change History (7)

comment:1 Changed 8 years ago by scottmc

Blocking: 7816 added

comment:2 Changed 7 years ago by 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.

comment:3 Changed 5 years ago by pulkomandy

Blocking: 6967 added

comment:4 Changed 4 years ago by pulkomandy

Blocked By: 7816 added
Blocking: 7816 removed

comment:5 Changed 22 months ago by 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.

comment:6 Changed 22 months ago by 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.

comment:7 Changed 22 months ago by 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.

Note: See TracTickets for help on using tickets.