Red Hat Bugzilla – Bug 381311
Last modified: 2008-02-06 18:35:22 EST
That's the stupidest config file I've ever seen. Please DON'T install it.
I believe that if you provide your "smart" ideas to help improve the rendering
setting of this font, it will be much better than throwing cold words to your
If you are an expert on fontconfig, please advise me how to write a conf file to
make this font be the default font when rendering Chinese characters (sans,
serif or mono), while using vector fonts for non-Chinese characters.
The reason that we raised the priority of this font is because the vector font
rendering of Chinese is terrible and hard to read, and the embedded bitmaps of
the default Chinese font, UMing, are neither complete nor optimized
(wqy-bitmap-fonts is based on those bitmaps and experienced 3 years of manual
fine-tuning). Because Uming is APL and not compatible with GPL, we are unable to
merge this to Uming.
1. Please post your fontconfig ruleset on email@example.com for review.
2. Due to longstanding fontconfig deficiencies you can not change font settings
just for chinese users, or just for the CJK blocks within your font. That means:
— your font priority needs to be lower than every other font that ships vector
fonts for non-Chinese characters, or you will stomp on those characters, and
users will complain.
— or you need to cull every non-CJK glyph from your font.
Please bug the fontconfig developpers to get fontconfig fixed if that is
inconvenient for you. I hear there are lots of people in China.
3. Another core problem is that some western developers have decided 96dpi is
good enough for screen text rendering and it's easier to force this resolution
than figuring out how to manage font scaling properly. (there is a large group
of them within GNOME). That prevents chinese users from getting higher-dpi
screens or using them in high-dpi mode if they already have them. If this
software limitation was lifted, CJK users could use screens with a sufficient
pixel density to render vector fonts properly without resorting to bitmap hacks.
Please bug the GNOME developpers so they handle high-dpi screens properly and
you can migrate from bitmap fonts mid-term instead of exhausting yourself
pushing a bitmap workaround like you're doing right now. Higher dpi screens have
been economically doable on a mass scale for a long time (and some vendors have
shipped them, and even a low-cost system like the OLPC has a high-dpi screen),
what prevents mass availability is software that refuses to support them.
The fedora fontconfig policy is there:
Created attachment 259111 [details]
The reported bug can not be repeated
This figure shows Fedora 8 under en_US locale when wqy-bitmap-fonts was
Latin fonts were displayed nicely with vector fonts. The wqy-bitmap-fonts does
not show up at all, even for rendering Chinese (we hoped that it could be used
in this case). From this figure, you can also see how vague the vector
rendering of Chinese characters. This has been complained for years, and almost
all people I know would replaced the blurry vector font by a bitmap Chinese
font or a hinted commercial font.
Created attachment 259121 [details]
The reported bug can not be repeated II (for zh_CN locales)
This one shows that even under Chinese locale (zh_CN), the Latin fonts were not
replaced by wqy-bitmap-fonts. Only Chinese characters were rendered by
wqy-bitmap-fonts. This makes the reading much more pleasant.
I'm not sure if that happend quite from the beginning of the
fresh F8 install, but at least after the latest update of the
wqy-bitmap-fonts package (0.9.9-1.fc8.noarch), the monospace
font in Firefox and Thunderbird was broken. No matter what
you configured there, you always got some Courier-looking
anti-aliased font. Only the font size was respected.
After removing /etc/fonts/conf.d/85-wqy-bitmapsong.conf
(or the complete wqy-bitmap-fonts package), everything was
Created attachment 267231 [details]
Before the fix: misalignment of Latin for monospace (console)
Before the patch, terminal will use wqy-bitmap-fonts for displaying Latin
characters (zh_CN locale), notice the "m/w/M/W" have overlaps to the next
Created attachment 267241 [details]
After the fix: monospace is displayed by vector font, Chinese will use wqy
After the patch, the Latin glyphs uses vector fonts (Dejavu LSG Sans Mono),
while Chinese characters use wqy-bitmap-fonts.
could you please attach a screenshot to illustrate your problem (before and
after using wqy-bitmap-fonts)? and, can you provide your locale and the output
of the following command:
fc-match -s "monospace:size=9pt" | head -10
The default wqy-bitmap-fonts installation (0.9.9-0) did not handle monospace
font rendering order properly. In console or other monospace environment,
fontconfig chooses to use the Latin glyphs in wqy-bitmap-fonts to display Latin
char and numbers. Because they are not monospaced, this caused misalignment of
characters in console (if one chooses monospace font), see Attachment #267231 [details].
In the new update (0.9.9-1), I perpended the system default monospace font
"DejaVu LGC Sans Mono" right before "WenQuanYi Bitmap Song". This will use
Dejavu Sans Mono to render Latin/numbers while using wqy-bitmap-song to render
Chinese for monospace environment. (see Attachment #267241 [details]).
Created attachment 267421 [details]
Firefox with wrong monospaced font in input area
Created attachment 267431 [details]
Firefox with correct monospaced font in input area
Created attachment 267441 [details]
fc-match -s monospace with wqy-bitmap-fonts installed
Created attachment 267451 [details]
fc-match -s monospace without wqy-bitmap-fonts installed
The command 'fc-match -s "monospace:size=9pt" | head -10'
does not show any difference, so I've appended the output of
'fc-match -s monospace' if that is of any help.
The attached pictures (snapshots of this bugzilla ticket ;-)
show and describe the problem (see and read the input text-area
within the pictures).
can you post your locale (run "locale" in a terminal)?
also if you can upload a screen capture of the firefox font configuration dialog
(menu Edit\Preferences\Content\Font&Color\Advanced) with the "correct"
configuration, that would be very helpful for me to do tests.
(In reply to comment #2)
> 2. Due to longstanding fontconfig deficiencies you can not change font settings
> just for chinese users, or just for the CJK blocks within your font.
Nicolas, this is not true. For Pango (and by extension Firefox) you can. I've
posted this before to the fontconfig list. For example:
<test name="lang" compare="contains">
<edit name="family" mode="prepend" binding="same">
Created attachment 267791 [details]
Firefox Font Configuration
(In reply to comment #1)
> I believe that if you provide your "smart" ideas to help improve the rendering
> setting of this font, it will be much better than throwing cold words to your
> peer developers.
> If you are an expert on fontconfig, please advise me how to write a conf file to
> make this font be the default font when rendering Chinese characters (sans,
> serif or mono), while using vector fonts for non-Chinese characters.
> The reason that we raised the priority of this font is because the vector font
> rendering of Chinese is terrible and hard to read, and the embedded bitmaps of
> the default Chinese font, UMing, are neither complete nor optimized
> (wqy-bitmap-fonts is based on those bitmaps and experienced 3 years of manual
> fine-tuning). Because Uming is APL and not compatible with GPL, we are unable to
> merge this to Uming.
You should only append to the generic aliases, never prepend. Just do that
before Uming gets a chance to do it. Mail fedora-fonts-list and we can help
you. In the mean time, please remove that file before more bug reports come in.
The font names "Zelvetica" and "Zourier" you see in my font config
are old friends. In fact, these fonts are copies of the old bitmap fonts
"Helvetica" and "Courier" which lived in /usr/X11R6/lib/X11/fonts/(75|100)dpi
in older RHL/Fedora releases. I simply made a copy of them and renamed all
occurences of "Helvetica" and "Courier" with "Zelvetica" and "Zourier" to avoid
naming conflicts with the new anti-aliased fonts of the same name.
Output of "locale":
ok, I will remove this file for now and hopefully we can figure out a more
robust solution in a relatively short time scale, with the inputs from
fedora-fonts-list (we may get bug reports filed from Chinese users if this
config file is removed).
I will also send a detailed email to fedora-fonts-list and elaborate the
motivation, goals and potential problems of setting up a pleasing Chinese
environment using wqy's fonts.
I apologize for the complication due to this config file, before we properly
handle the font matching problems of both Latin&Chinese characters, please
temporarily remove wqy-bitmap-fonts to restore your default settings. I will let
you know when the new config file is committed if you choose to use
wqy-bitmap-fonts in the future.
Thanks Qianqian. Excuse my tone if I offended you earlier. Didn't mean to.
hi Behdad, that's no problem.
I just sent a long email to fedora-fonts-list, and I hope that you may have time
to read it and give me advices to improve this config file.
wqy-bitmap-fonts-0.9.9-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 379351 has been marked as a duplicate of this bug. ***
*** Bug 241551 has been marked as a duplicate of this bug. ***
I see you only pushed this to F8, can you please push it to F7 too? (FC6/FE6 is
no longer supported, unfortunately.)
a new fontconfig file was provided with the inputs from fedora-font-list.
you can find it at
(save the attached fontconfig file as /etc/fonts/conf.d/61-wqy-bitmapsong.conf)
this is the one currently used in devel, and seems working fine with non-zh
locales (Jens and his colleagues had tested it).
Can you remove 85-wqy-bitmapsong.conf, and install 61-wqy-bitmapsong.conf on
your system? if things are working fine, I would be glad to push it to F7.
Might be better to clone a bug for F7?