[Bug 39185] Lack of per-script font selection makes reading pages in script not covered by the main font difficult.

[James Richard Tyrer]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=39185         




------- Additional Comments From tyrerj acm org  2008-06-25 23:42 -------
This problem isn't going to be fixed in Qt because TrollTec thinks that Unicode is the answer to such issues.

1.  For the Generic font names, the problem needs to be handled in FontConfig and the solution would be a KDE applet to set this up.  You need to be able to choose a default font for each of the 5 generic font names and then for a selected encoding, or Unicode page, choose an override.

2.  For HTML (etc.), the answere would appear to be what FireFox uses.  You can choose a default font for three of the generic fonts for each of the listed languages *and* it allows you to choose overriding the fonts specified for these in the HTML code.

3.  For KDE: where you choose a font, you need to also be able to choose an overrid for a selected encoding or Unicode page.

The problem is that this doesn't always solve the problem.  The reason is that the encoding, or unicode page, does not always determine the language being used.  Specifically, Japanese, Korean, 3 types of Chinese (and then there is  Canadian [yes Canadian]) can not always be determined by the encoding, or Unicode page. 

HTML pages contain a locale code, so that should solve the problem there.  But, how do we solve it for other cases?  The above would appear to be a great improvement, but there may still be problems.  Specifically with CJK languages there is the Han unification issue -- these characters have the same Unicode character code and the same meaning but the actual glyphs are going to be different in Japanese, Korean, and the 3 types of Chinese.

Wordprocessing documents could contain locale codes.  Documents that are text/plain do not even contain an encoding and (therefore) requires the user to tell the system what the character encoding is.  Email appears to still be based on character encoding although it could contain a locale code.

It was claimed that GTK (or actually Pango) fixes this, how does it do this?

So, IMHO, this is still an issue that can be partially resolved but still needs some additional work to totally resolve it.