Bug 235554 - Fonts with embedded bitmaps does not display well unless antialiasing is turned off
Summary: Fonts with embedded bitmaps does not display well unless antialiasing is turn...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: freetype
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact: Brock Organ
URL:
Whiteboard: bzcl34nup
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-07 07:45 UTC by r6144
Modified: 2008-05-06 19:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-06 19:28:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
fontconfig configuration file used in the workaround (1.71 KB, text/plain)
2007-04-07 07:45 UTC, r6144
no flags Details

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
bitmaps:

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
pango-view.

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
yesterday.

fontconfig-2.4.1-3.fc6
freetype-2.2.1-16 (rebuilt from the source RPM after turning on the bytecode
interpreter in the spec file)
pango-1.14.10-1.fc6
cairo-1.2.6-1.fc6
libXrender-0.9.1-3.1
xorg-x11-server-Xorg-1.1.1-47.7.fc6

How reproducible:
Always

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 bugzilla.freedesktop.org.  Otherwise, bugzilla.gnome.org
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 http://fedoraproject.org/wiki/BugZappers

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.


Note You need to log in before you can comment on or make changes to this bug.