Bug 507697

Summary: Font preview does not work well in a non-English environment
Product: [Applications] systemsettings Reporter: Huanyu Liu <1293660441>
Component: kcm_fontinstAssignee: Plasma Bugs List <plasma-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: kde, nate
Priority: NOR    
Version First Reported In: 6.3.5   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Bad font preview

Description Huanyu Liu 2025-07-31 14:41:30 UTC 
Created attachment 183678 [details]
Bad font preview

SUMMARY
Font preview does not work well in a non-English environment. Depending on the font, some characters may be rendered as tofu. Additionally, the default preview text is associated with the system language, not the language(s) supported by the font. See "ADDITIONAL INFORMATION" for details.

STEPS TO REPRODUCE
1. Switch your system language to a non-English one (e.g. Simplified Chinese)
2. Go to "Font Management" module in System Settings
3. Select a font and observe the font preview

OBSERVED RESULT
Depending on the font, some characters may be rendered as tofu. See the attachment.

EXPECTED RESULT
There should be no character rendered as tofu ideally.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.1
Kernel Version: 6.15.1-arch1-2 (64-bit)
Graphics Platform: Wayland
(For some reasons, I haven't updated my system for a while, but this bug should persist in newer versions.)

ADDITIONAL INFORMATION
Take the attached image (Fira Sans) for an example.

Firstly, there are two blocks of tofu after the font name. It should be "常规", which means "Regular". By the way, according the source code at https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/kfontinst/apps/Printer.cpp , the font name should be typeset with the 12pt "sans" font in boldface. However, it is actually typeset in regular weight. Maybe it should be "sans-serif" instead of "sans"?

CJK users usually use complex fallback mechanisms for CJK text display. For example, in my fontconfig configuration, "sans-serif" is an alias for the list [Noto Sans, Noto Color Emoji, Noto Sans Symbols, Noto Sans Symbols 2, Noto Sans Math, Noto Music] at first. After that, I add some language test and append Noto Sans CJK SC/TC/HK/JP/KR accordingly. I'm not sure whether the font preview can handle such a complex case.

Secondly, there are some blocks of tofu after "The Quick Brown Fox Jumps Over The Lazy Dog". It should be "龙跳天门，虎卧凰阁", which is the default preview text for Chinese. Since Fira Sans does not contain any CJK characters, those are rendered as tofu naturally.

However, that indicates a problem in the current font preview mechanism. The default preview text is associated with the system language, not the language(s) supported by the font. As a result, the preview text for a English font becomes tofu in a Chinese environment, and the default preview text in an English environment is meaningless for a Chinese font.

In summary, I would highly appreciate it if the problems mentioned above could be fixed. It is a crucial step for multilingual support that will benefit all non-English users.
Comment 1 David Edmundson 2025-07-31 15:21:39 UTC 
How would you suggest going about fixing this? Some big fonts do support latin and chinese.

If we had a drop-down in the preview area to choose a language that only showed available options would that work?
Comment 2 Huanyu Liu 2025-08-01 08:00:28 UTC 
(In reply to David Edmundson from comment #1)
> How would you suggest going about fixing this? Some big fonts do support
> latin and chinese.
> 
> If we had a drop-down in the preview area to choose a language that only
> showed available options would that work?

Ideally, kfontinst should be able to detect the supported languages automatically, but it is not easy to implement. If you open a font with FontForge, you will find the (declared) supported Unicode/Codepage ranges at "Font Info > OS/2 > Charsets". However, these two fields are arbitrarily editable, so it might be inaccurate.

Furthermore, supported *languages* cannot be implied from supported *Unicode ranges*. For example, a font designed for French must support the "Latin-1 Supplement" Unicode range (or the "Latin-1" codepage), but may only support necessary letters for French, so it cannot be used for German, which also requires the "Latin-1 Supplement" Unicode range.

We can make a rough guess based on supported Unicode/Codepage ranges, and put all possibly supported languages into a drop-down. In case of failure, the user should be given the freedom to select another language. This can be done by putting a "More languages..." at the end of the drop-down.

This also requires that the preview text for all languages be extracted to a separate map that is always accessible, regardless of the current system language. A hand-written map from Unicode/Codepage ranges to possible supported languages is also required.

If the language detection part is too difficult to implement, we can just stuff everything into the drop-down, and let the user make the choice.