Identifying text rendering problems

This page needs some love
This page should be revised or reconstructed to be more helpful. Problems may include being out of step with current team or project status or process.

This article is unfinished
It needs editorial work, and may not be accurate. Don't rely on it.

    * From: Ben Laenen <benlaenen gmail com>
    * To: fedora-fonts-list redhat com
    * Subject: Identifying text rendering problems
    * Date: Sun, 11 Nov 2007 17:50:26 +0100

Hi all,

I've written up a bit of text to help with point 8 on the 
http://fedoraproject.org/wiki/SIGs/Fonts/Todo page given our experience 
with DejaVu.  Finding out what is causing text rendering issues may be 
quite hard to describe, especially since we never follow some certain 
pattern to get to what the problem is with the bugs we get reported 
with DejaVu.  It's usually just experience with what problems are 
related to certain issues that immediately tells us what's wrong.  
Furthermore, the variety of possible text rendering problems is very 
big.  Nevertheless, I've tried to compose some summary here describing 
what could go wrong.  Just keep in mind that I've certainly not covered 
all issues here.


I'll only address issues here which one could encounter with normal 
opentype truetype fonts (ttf).  For opentype fonts with CFF outlines 
(otf) this will probably be somewhat the same, except that all BCI or 
autohinting issues should be discarded here, and replaced by postscript 
hinting issues.

Bitmap fonts probably have their own issues, I'm not looking at those 
here.

Also, I'm aware Fedora doesn't enable the BCI in FreeType by default, 
but many users do enable it, so I'm not discarding the issues of BCI 
hinting here.  Most of the bugs reported to us btw relate to bad 
autohinting, so it's usually the first thing we will test.

Final note: I don't take subpixel hinting into account here. It's 
possible that some issues occur only when subpixel hinting is enabled, 
but I don't think we ever got reports for those (and I still use an old 
CRT screen, so I don't use subpixel hinting myself)



I would say there are three kind of bug reports we get:

1 a certain glyph looks bad
2 glyphs are placed incorrectly
3 user preference issues

so let's see how we handle these.


1. a certain glyph looks bad

Caveat: is the user sure he sees the font he reports an error for. Font 
substitution could be at work and he may look at a completely different 
font which has a bad glyph.

Suppose the shape of a glyph looks bad. Again, there are two categories 
here:


1.a the shape is just wrong

This means the font should be fix the shape.


1.b the glyph looks bad at specific font sizes

This is where we try to determine whether the user who reports the error 
is using the autohinter, or the bytecode interpreter (BCI).

We made life a bit easier in DejaVu by adding the glyphs U+F000 and 
U+F001 in Sans, which show 88 when the BCI isn't used (i.e. he is using 
the autohinter) and the font pixel size when BCI is enabled.

If the user uses the autohinter, it is most likely a autohinter problem 
and the problem should be reported to FreeType.

If the user uses BCI, the font has bad hinting instructions for the 
glyph and the font needs to fix it.  It's also possible that the BCI of 
the renderer is buggy.

In reporting the bug to the font, it's important to tell them the pixel 
size (not point size, because that's variable on dpi settings). As said 
before, for DejaVu the U+F000 and U+F001 give the pixel sizes.


1.c a glyph looks too fuzzy compared with other glyph

The user probably has BCI enabled and is using a glyph from a font which 
doesn't have that glyph hinted.  Solution: persuade the font authors to 
hint the specific glyph.


2. glyphs are placed incorrectly

Again, many different possible issues here:


2.a bad spacing between glyphs

Test out if the spacing is still bad at very big font sizes.  If it is: 
the font probably has bad bearings (space between the glyph outlines 
and the glyph boundaries) for a specific glyph. The font could also 
have bad kerning.

If the spacing is nice at big font sizes or when it only happens at 
specific sizes, it's again likely a autohinter or hinting bug. See 1.b


2.b accents are badly placed (for precomposed glyphs)

Again, test out for big font sizes have the issue as well. If it looks 
bad as well then, the font has the accent badly placed in the 
precomposed glyph.  If it looks bad at only specific sizes, the font 
maybe need to adjust the accent with hinting, or autohinting is placing 
it incorrectly. Also see 1.b


2.c combining diacritics are badly placed on base glyphs

First question to answer: does the user have a renderer which can 
properly handle anchors (Pango, Qt4) or not.  If he doesn't (Qt3 for 
Latin for example), then there's not much to do, except to convince the 
people in charge of the renderer to support it (in case of Latin in Qt3 
it probably won't happen since new versions of Qt4 handle them).

If the renderer can handle anchor placement, some things can be wrong:

- The font may have bad anchor placement
- The font has no anchors at all (or it has no anchors for that specific 
base glyph - mark combination (but in that case the renderer should 
have some fall-back option for default placement. Qt4 has it, Pango 
IIRC not, but it may have changed by now with Harfbuzz)

Other issues which could relate to a renderer problem or a font problem:
- Diacritics on wrong part of ligature (could be an anchor issue in the 
font, or a renderer problem)
- "Extreme diacritic testing" (read: not many users do that), i.e. one 
or more base glyph with a big amount of diacritical marks, or with 
special marks like CGJ (combining grapheme joiner) (again, could be a 
anchor issue, but if the font handles normal cases nicely it's likely 
that the renderer will get confused or isn't build to handle the 
specific string with CGJ)



3. User preference issues

These usually aren't bugs, but do get reported from time to time, so I 
put this section here anyway.

- Font looks fuzzy overall (sometimes reported as: too thick; or 
sometimes also: fonts are too sharp, usually reported as: too thin):

The user should play with hinting settings and preferably enable BCI 
when he finds the fonts too fuzzy (patent issues aside).  The 
autohinter sometimes doesn't make the glyphs sharp enough.  Also, is 
the font hinted?  If not, then he should try to get autohinting enabled 
only for that font (todo: look up some fonts.conf for that...).  When 
the font isn't fuzzy enough (i.e. too sharp) BCI is probably not 
something the user wants, and he may want to try out several settings 
of the autohinter, or no hinting at all.

Depending on the platform he uses (KDE, Gnome...), give the user 
fonts.conf configurations, or direct him to the proper dialogs to get 
the fonts to the way he likes them best.

- Fonts are bitmapped/aliased, which looks bad; or: fonts are bitmapped, 
and I want them to, but they look very bad.

If the user doesn't want bitmapped fonts, it's easy: just enable 
antialiasing.

If he wants bitmapped fonts but they look bad: the amount of fonts made 
to look nice bitmapped are very few (the old MS corefonts for example, 
but making fonts like this has the oddity that it will sometimes have 
bad hinting when antialiasing is enabled), so usually the bad look is 
to expect.  If the user uses one of the corefonts for example and they 
look bad, he probably makes use of the autohinter, since these fonts 
will also look nicely as bitmaps only when BCI is enabled.

Fonts in Fedora
The Fonts SIG takes loving care of Fedora fonts. Please join this special interest group if you are interested in creating, improving, packaging, or just suggesting a font. Any help will be appreciated.