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
participants (2)
-
khchan2@study.csis.hku.hk
-
Mike Fabian