Created attachment 301476 [details]
Screenshot attached illustrating the problem

That's WQY Bitmap Song, right?

I guess this is still the "WQY claims latin letters" problem, gedit is just 
using a latin font, Konqueror is using the WQY font throughout (which looks bad 
for latin letters).

(In reply to comment #2)
> That's WQY Bitmap Song, right?
> 
> I guess this is still the "WQY claims latin letters" problem, gedit is just 
> using a latin font, Konqueror is using the WQY font throughout (which looks bad 
> for latin letters).

Yes, WQY Bitmap Song, it is.

I did not get any "bold style" appearance for Chinese fonts on F9 for QT/KDE 
apps.

Bold style is OK for my QT/KDE apps onF8.

Most Qt/KDE apps in F9 are Qt 4, most Qt/KDE apps in F8 are Qt 3, those are 
very different codebases especially in this domain (font rendering).

Please try Qt/KDE 4 apps in F8 (e.g. marble) and/or Qt/KDE 3 apps in F9 (e.g. 
KMail in kdepim) for a fair comparison.

(And sorry for nitpicking, but it's "Qt", not "QT". ;-) )

;-) just press shift for input "qtkde"...

Thanks.I'll try kmail later, since my F9 is beta with latest rawhide.

take a look at http://www.linux-ren.org/modules/everestblog/?p=131

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Is this still an issue with the latest KDE 4.0.5?

To my opinion, this bug shall be filed to Qt or Xft. Let me explain:

With earlier versions of Xft library, fake-bold (automatically emboldening a
bitmap glyph produce its bold face) was not supported
(http://lists.freedesktop.org/archives/xorg-bugzilla-noise/2004-October/003643.html
). So, since the first release of wqy-bitmap-fonts, we have been including a
pre-made bold face for each bitmap size (9-11pt). We recently stopped doing that
(http://wenq.org/forum/viewtopic.php?t=655), because we thought that Xft is
mature enough for emboldening bitmaps if bold face is not provided. I updated
the wqy-bitmap-fonts to reflect this change for Fedora. This also halve the file
size for this package.

The reported bug seems more like that Xft/Qt is not correct/consistent in
handling automatic-emboldening bitmap fonts when bold face is missing. I would
suggest either assigning this bug to kde/qt rendering library, or Xft. More
input is also welcome to clarify the accurate source of this problem.

just realized Baif had found the right solution to this problem in his reply on
May 9. Has this patch been accepted by KDE4 team?

This type of patches has to go to Trolltech, not KDE, and (unless it's already 
in 4.4) it will most likely not get in before Qt 4.5. Moreover, Qt 3 no longer 
gets updated, so if Qt 3 doesn't currently support this, this feature will 
never be supported in Qt 3.

I am still not really convinced any bold font is involved here in this report.
To me it just looks to be the contrast of the light Chinese font and
the dark Western font, no?  I have generally found Chinese fonts to be pretty
faint but maybe it is necessary for them to be so fine to be able
render very detailed Hanzi characters?

I think there was some discussion somewhat related to this pango issue
between Qianqian and Behdad not so long ago on fedora-fonts-list IIRC
and also elsewhere.

Shao, I think if you specify a Chinese font in the gedit preferences it looks
ok, no?
So I think this is really comes down to pango.  We could try reassigning to pango,
but unless someone has some real ideas how to improve it upstream
it is probably unlikely to get changed yet.

(But sure, I guess the Qt embolden issue is worth pursuing upstream.)

If the problems are reported against QT apps I sort of doubt pango is involved.

It would be nice to have a confirmation it works as expected in a pango app such
as gedit though.

(In reply to comment #14)
> If the problems are reported against QT apps I sort of doubt pango is involved.

No, the complaint was that the rendering in konqueror and gedit is different.
Actually Qt seems to be doing the right thing here and it is pango that is
using a different font for the Western characters in the screenshot as is
a well-known problem.

Sorry, Behdad...

I take back my Comment #10, which seems to be an unrelated issue with this bug.

I agree with Jens, this is somewhat related to Pango, but I think it is likely a
not-a-bug.

The title of the bug is not accurate: what the submitter complained about is the
mixing of bitmap Hanzi glyphs with Anti-aliased vector glyphs (he called it bold
effect). This might well be a designed feature: if he selected "monospace" as
font family, based on the fontconfig setting of wqy-bitmap-fonts, we will use
"Dejavu Sans Mono" to display Latin glyphs, and wqy-bitmap-fonts to display the
Hanzi glyphs. So, it looks correct to me. If the submitter prefer to use
wqy-bitmap-fonts for all glyphs, he should select "WenQuanYi Bitmap Song" as the
font name in gedit.

If the submitter was complaining about the digits (such as "302" and "320") are
inconsistent with Latin glyphs, then I would like to direct him to the old
discussion with Behdad: 
http://www.mail-archive.com/fedora-fonts-list@redhat.com/msg00191.html

If the submitter or any of the reporters selected "bold" style and did not get
any bold faces displayed, I think he should file a separate bug, as it is
different from what the submitter originally reported.

requested by Jens Petersen (#27995)

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Is this still reproducible in F10 or F11?
And do we have any clue which component(s) is/are actually at fault here and what needs to be fixed?

I verified this bug in kdebase-4.1.2-5.f10, and I find this bug can not be reproduced now, so I will close this bug.