Identifying text rendering problems

* From: Ben Laenen * 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.