My earlier problem of character alignment has been resolved by only a click - I disabled Anti-aliasing and all the display problems in Kate and kwrite are resolved. Although Anti-aliasing seems to work on your system, for unknown reasons it doesn't work for me. Perhaps later on I will do more tests and see if there is anything I can come up with. The reason I asked if there are alternate Chinese fonts is that the Arphic fonts installed are very difficult even to identify the characters themselves at small font sizes (around 12). In Windows the default "mingti" font is quite readable at small font sizes, but this is not the case for Arphic. Both Chinese and Latin characters are not that easy to look at. I heard that KDE 3 has better support for i18n and non-Latin characters. Did anyone try the Alpha1 release?
khchan2@study.csis.hku.hk writes:
My earlier problem of character alignment has been resolved by only a click - I disabled Anti-aliasing and all the display problems in Kate and kwrite are resolved.
Although Anti-aliasing seems to work on your system, for unknown reasons it doesn't work for me. Perhaps later on I will do more tests and see if there is anything I can come up with.
Thank you. I have no idea at the moment why it works for me but doesn't for you.
The reason I asked if there are alternate Chinese fonts is that the Arphic fonts installed are very difficult even to identify the characters themselves at small font sizes (around 12). In Windows the default "mingti" font is quite readable at small font sizes, but this is not the case for Arphic. Both Chinese and Latin characters are not that easy to look at.
Do the "mingti" Fonts contain embedded bitmaps (sbit)? I suspect that they do. Many fonts on Microsoft Windows contain embedded bitmaps for small sizes, for example the Japanese "msmincho.ttc" and "msgothic.ttc" contain such sbit-bitmaps. The free Japanese "Kochi" TrueType fonts available on SuSE Linux 7.3 contain sbit-bitmaps as well. The Arphic fonts however don't contain sbit-bitmaps. You can find out whether a TrueType font contains sbit-bitmaps by looking at the output of ~$ ftdump fontname.ttf The rendering of outline fonts at small sizes often produces less then perfect results, if the TrueType fonts contain sbit-bitmaps in addition to the outlines and the rendering mechanism supports sbit, the bitmaps are preferred for the sizes at which they are available. This can result in much better readability at small sizes. If you don't use anti-aliasing on linux, your TrueType fonts are rendered either by the "freetype" or the "xtt" module (look into you /etc/X11/XF86config to find out which one you are using or to change it). Both the "freetype" and the "xtt" module use the freetype1 library. "xtt" supports sbit already for a long time. In SuSE Linux 7.3, the "freetype" module also contains a patch which adds sbit support. When sbit support is available and you have fonts with sbit, fonts will look much better at small sizes. Xft, which is used when you use anti-aliasing uses the freetype2 library. Xft currently does not used embedded sbit-bitmaps. It's even worse, if freetype2 has been compiled with the byte code interpreter switched on, Xft will show ony huge amounts of white space and no characters at the sizes where embedded bitmaps are available in a font. The byte code interpreter is switched of in SuSE Linux 7.3. due to possible problems with some patents by Apple. If you don't use fonts with sbit, have a license by Apple or live in a country where Apple's patent doesn't apply, you may want to switch on the byte code interpreter, then your antialiased fonts will look better. For information on how to switch on the byte code interpreter, please read this: http://wwwsg.suse.de/~mfabian/suse-cjk/byte-code-interpreter.html -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
participants (2)
-
khchan2@study.csis.hku.hk
-
Mike Fabian