Please take a look at this, I don't know what it should look like...

Could this be related to kde-i18n using old-style po files?

I don't know it caused by old stuff, but I'll check kde-i18n.


BTW, strange to say, if I selected the TrueType fonts (utf-8 encoding)
and enable AA-displaying, it looks fixed.

AP people may be able to fix this bug.

And fix this both with bitmap fonts and TT fonts.

This defect is considered SHOULD-FIX for Fairfax

kcontrol: [look & feel] -> [font]:
To change the font to use normal (not bold which is the defalut) one
for the title of the window may fix this problem.

Which is the part to specify to use the _bold_ (not normal) font
for the title of the window? And why is the bold font specified?

The first available font on the font list (ie. xlsfonts | grep jisx) of normal
and bold font is a ttf, qt's fontguess took those ttfs to generate fontsets. 

Because xfs does not recognize the TTCap parameters in fonts.{scale,dir}, hence
it does not load the bold fonts for ttf. xtt module supports the TTCap
parameters. To fix bug 50145 and also able to use ttf bold font:

Edit /etc/X11/fs/config:
comment /usr/share/fonts/ja/TrueType

Edit /etc/X11/XF86Config-4:
  In Section "Files"
    Add FontPath "/usr/share/fonts/ja/TrueType"
  In Section "Module"
    Add Load "xtt"

restart xfs, reload X11 (ie. init 3; init 5)

This should fix this problem. 

I see. The way you told doesn't only efficient for this problem
but also fix #50941.

Thanks!

So it is a bug against XFree86-xfs and anconda.
since there is no XFree86-xfs component,I point to XFree86-jpfonts.

Aaron,would you please add XFree86-xfs component in bugzilla?

The xfs support for asian language font extensions is going to be accross
japanese/korean/trad chinese/simp chinese.  

The solution lies either with modifications to the XF86Config file or patches to
xfs, so perhaps this should be assigned against XFree86?

About xfs, we have made some progress. Briefly, within X, there are two sets of
TrueType font handling codes, one called FreeType, the other is
Xtt which is developed by Japanese mainly for CJK fonts. One of these should be
linked to the libXfont library, either FreeType or Xtt, so xfs
can use.

At the moment, FreeType code is compiled and linked to libXfont, this is the
default configuration.  This is also why we have problems with CJK fonts. What
we need to do is just strip the FreeType code, link Xtt code into libXfont.

Right now, I've got some problems when compile Xtt to a shared library, by using
"
#define BuildFreeType NO
#define BuildXTrueType YES
#define XTTInLibXFont YES"
in spec file, the new libXfont still doesn't work. We are still debugging here
in Brisbane, anybody has any idea about this?

BTW, is there any reason we intentionally built FreeType into libXfont before?

I think this problem is ttfonts-ja, ttfont-ko, ttfont-zh_CN
ttfont-zh_TW.

There is a member of xtt is in Japan office, and he says xtt
is sucks, and will never be maintained. So I don't want to use
xtt unless there is so fatal reason.

TTCap extension examples:

Here are 3 lines took from fons.dir with TTCap extension:

bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-medium-r-normal--0-0-0-0-c-0-big5-0
ai=0.3:bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-medium-i-normal--0-0-0-0-c-0-big5-0
ds=y:ai=0.3:bkai00mp.ttf -Arphic Technology Co.-AR PL KaitiM
Big5-bold-i-normal--0-0-0-0-c-0-big5-0

Basically, the first line tells xtt how to generate the normal font. The second
line, by
using TTCap extension "ai=0.3", xtt knows how to generate fonts by slanting 0.3
(units, some degree ...). The third line's "ds=y" means "double striking of the
face", so we got the bold font.

Details: http://x-tt.dsl.gr.jp/doc/cur/INSTALL.eng

We are in freeze, so any changes made to fix this, *must* not be
far reaching.  IOW, switching core library code from freetype to
xtt is definitely a no-no.  I dunno how this will end up being
resolved, but it should be done in a way that is not going to
destabilize the XFree86 release.

I have added .ttc to the xfs initscript so that .ttc files are now
caught also when xfs starts up.  Hope this also helps with CJK for
you guys.  Let me know if there is anything I can help with.

I've also Cc'd Owen.  Please Cc Owen and myself on any font issues.
Thanks.

The questions that comes to my mind are:

 - Where are the bold fonts that KDE is trying to use configured?
 - Can we configure them to use the non-bold fonts for bold
   as well?

This may be a solution for Fairfax:
Make sure you have taken all the fonts with medium and bold. 
e.g.
-wadalab-gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
-wadalab-gothic-bold-r-normal--0-0-0-0-c-0-jisx0208.1983-0

modify changes to fonts.scale, fonts.dir
touch fonts.dir (prevent xfs script to run ttmkfdir to regenerate the file
again, as it has some problems detecting CJK charsets on some ttf fonts)

Restart xfs. You should able to use "bold ttf font" (it will still use normal
type instead of bold type, however this should solve the problem)

P.S. as a safely-net, in CJK ttfonts spec file, at post-install, may need add
"touch fonts.dir" to prevent xfs script updates fonts.{dir,scale}

Any progress made on this ssato?

IMHO, the best solution is to extend Freetype to support what is required,
or xfs.. depending on where the specific problem lay.  This is likely something
that will have to be done upstream however unless Owen or someone else familiar
or brave enough is willing to dig into it.

Can someone update the status of this?

Since there hasn't been any feedback on this bug in ages, and I've
pinged twice above about it, I presume the problem is no longer
present, and am closing this bug.