From Fedora Project Wiki

m (1 revision(s))
No edit summary
Line 1: Line 1:
= Reporting, verifying and getting fixed text rendering issues =
= Reporting, verifying and getting fixed text rendering issues =
{{:SIGs/Fonts/CompactHeader}}


{{Anchor|text-ecosystem}}
{{Anchor|text-ecosystem}}

Revision as of 15:56, 25 May 2008

Reporting, verifying and getting fixed text rendering issues

Text rendering ecosystem

Modern text rendering is a complex process that involves many components:

  • font files,
  • a font discovery and substitution library (usually Fontconfig, but Java uses its own solution),
  • a font rasterizer library (usually Freetype nowadays, but again Java uses its own solution),
  • a text layouter library (Pango for GNOME, internal QT library for KDE, ICU for OpenOffice.org, HarfBuzz for future GNOME & QT),
  • the settings the application passes to those components, sometimes taken from Xorg.

It all works roughly that way: 1. application passes:

  • a string of unicode points,
  • language information,
  • target media dot density, DPI (used to convert font sizes in universal units like points to measures in number-of-dots)
  • desired font (name, variant, size)

2. the font discovery and substitution library is used to find the requested font, and complete it/replace it with other fonts if needed (typically, requested font not present or lacking some of the glyphs needed to render the unicode string). If this library is misconfigured non-optimal substitutions will happen. 3. the text layouter library positions the glyphs based on the language information, in-font information tables, and internal library rules. It can choose to replace some glyphs with others (ligatures, etc) 4. the font rasterizer library renders those glyphs to the target media dot density. Unfortunately computer screens typically do not have a pixel density high enough to do direct glyph scaling without getting human-visible rounding artifacts. The rasterizer library must distort glyph shapes so they fit as much as possible in the pixel grid. This distortion process uses either in-font instructions (hints) and a patented algorithm, or on FLOSS systems like Fedora a process called autohinting.

The root cause of a text rendering problem can occur at any of those stages, in any of the components involved. Identifying the problem and getting it fixed will therefore often require interaction with the font designers and the developers of several of those software components. While not overly difficult or long, QA process on text rendering is not for fly-by bug reporters.

Process

Given this [#text-ecosystem complexity] , the most efficient process for everyone involved is not to blindly report problems in Fedora bugzilla , but to do the following: 1. Consult the [#known-problems known problems] list to check if your issue has not been reported before. 2. If that is the case, you can increase issue visibility and decrease its resolution time by: 1. adding a polite comment in the issue tracker, 2. putting yourself in CC, 3. voting for the issue when it's possible. 3. Otherwise: 1. ask help on the SIG list or the ##fonts irc channel to identify what component is likely to cause the issue[[FootNote(You can also find clueful help on the #dejavu irc channel)] , 2. report it directly in the upstream issue tracker of the affected component, 3. notify the SIG by CC-ing the SIG bugs list in the upstream issue tracker. 4. If you find the issue very impacting, you can add a new bug in Fedora bugzilla pointing to the upstream issue.

Identifying fonts

Sometimes all the fontconfig substitution and composing magic makes it hard to identify the font files responsible for a mis-rendering. The font family applications typically display is the requested family, not what this request has been resolved to for a particular glyph.

Looking up this glyph in the gucharmap application, using the same font family, is usually sufficient to learn where it's taken from. Gucharmap will display the origin font when you right-click on a glyph[[FootNote(Note, however that pango-enabled apps will not substitute glyphs on a per-glyph basis, but will try to take surrounding glyphs into account. Thus they may not use exactly the same rules as gucharmap, and you may need to check several fonts in gucharmap before finding where a glyph is taken from.)] .

File:SIGs Fonts QA gucharmap.png

In-depth font testing

Pravin Satpute published this nice How to test OpenType Fonts article.

Known problems

Problems are tagged by CC-ing the SIG bugs list when the upstream issue tracker allows it (any bugzilla) or by CC-ing a specific user (fedorafonts) otherwise.


Idea.png
Tagging problems
Problems are tagged by CC-ing the SIG bugs list when the upstream issue tracker allows it (any bugzilla) or by CC-ing a specific user (fedorafonts) otherwise.


Issue tracker Description Issues Tagging method and other comments
bugzilla.redhat.com Fedora package grouping (comps), specific Fedora code changes Problem list CC the bugs list
bugzilla.freedesktop.org Fontconfig, HarfBuzz, DejaVu, Freetype… Problem list
bugzilla.gnome.org Pango Problem list
bugs.kde.org KDE (Konqueror…) Problem list
bugzilla.mozilla.org Firefox, Thunderbird… Problem list
bugs.webkit.org Webkit Problem list