Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 235554

Summary: Fonts with embedded bitmaps does not display well unless antialiasing is turned off
Product: [Fedora] Fedora Reporter: r6144 <rainy6144>
Component: freetypeAssignee: Behdad Esfahbod <behdad>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: triage
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 19:28:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
fontconfig configuration file used in the workaround none

Description r6144 2007-04-07 07:45:22 UTC
Description of problem:

The NSimSun font (the Chinese font simsun.ttc from Windows XP) has embedded
bitmaps for the Chinese glyphs at pixel sizes 12-16, but apparently there are no
embedded bitmaps for ASCII characters, as these characters remain antialiased in
ftview even when embedded bitmaps are turned on at the correct sizes.

This font always renders correctly in ftview.  However, two rendering problems
appear in GNOME applications when the font is used at the sizes with embedded

1. If sub-pixel rendering is turned on, the Chinese characters disappear in many
applications.  The sample in the font selection dialog looks okay, and so does
the text rendered in pango-view, but the Chinese characters disappear in all
GNOME applications if NSimSun is set as the dialog font.

2. If ordinary (not sub-pixel) antialiasing is enabled instead,  the Chinese
characters show up correctly as the embedded bitmaps, but the ASCII characters
(which do not have embedded bitmaps) are barely readable, in particular the
digit "4" at pixel size 16 looks much like "1".  This problem is visible in

The ASCII characters do not appear antialiased at these sizes, and they look
much worse than the "correct" non-antialiased rendering, as if they had been
rendered without hinting, or the antialiased rendering had been converted to
black-and-white before being displayed.

Both problems disappear when I manually disable antialiasing at the sizes with
embedded bitmaps by putting the attached file into /etc/fonts/conf.d.  This
workaround works well, but it is cumbersome to find out all the sizes with
embedded bitmaps.

Version-Release number of selected component (if applicable):

I'm not sure of the exact component causing the problem, so I list some likely
candidates below.  The system is Fedora core 6, and a full update has been done

freetype-2.2.1-16 (rebuilt from the source RPM after turning on the bytecode
interpreter in the spec file)

How reproducible:

Steps to Reproduce:
1. Build freetype with bytecode interpreter support (not sure if this is necessary)
2. Set up fonts.conf so that the NSimSun font can be found by fontconfig.
3. Open some GNOME applications with LANG=zh_CN.UTF-8, e.g. by choosing
Simplified Chinese as the language when starting the session.
4. In gnome-font-properties, turn on subpixel rendering, set DPI to 96, and
change the dialog font to NSimSun at 11pt.  After clicking OK, the Chinese
characters in most applications (e.g. the clock applet) should disappear,
including the Chinese messages in gnome-font-properties itself if it had been
started with LANG=zh_CN.UTF-8.
5. Now turn off subpixel rendering and use ordinary grayscale antialiasing.  The
Chinese characters should reappear, but the digits in the clock applet look bad,
in particular the diagonal stroke in "4" totally disappears making it appear
like "1".
6. When antialiasing is disabled at these sizes via the attached fontconfig
file, the result looks correct in both cases.

Actual results:
See above.

Expected results:
The Chinese characters should appear and the ASCII characters should be quite
readable at that size.

Additional info:

Comment 1 r6144 2007-04-07 07:45:22 UTC
Created attachment 151909 [details]
fontconfig configuration file used in the workaround

Comment 2 Behdad Esfahbod 2007-04-08 22:24:24 UTC
Can you write a cairo test case and see if it's a cairo bug?  In that case,
please open a bug at  Otherwise,
would be better.  But given that the font is not freely available, you are
basically on your own debugging it for now.

Comment 3 Bug Zapper 2008-04-04 06:47:47 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out

Comment 4 Bug Zapper 2008-05-06 19:28:33 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.