Line 5: | Line 5: | ||
== Text rendering ecosystem == | == Text rendering ecosystem == | ||
{{:Font_rendering_and_text_layouting}} | |||
{{ | |||
== Process == | == Process == |
Revision as of 09:58, 26 June 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[1],
- a font rasterizer library[2],
- a text layouter library[3],
- the settings the application passes to those components, sometimes taken from Xorg.
The root cause of a text rendering problem can occur 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.
See also this article for additional information.
Process
Given this complexity, the most efficient process for everyone involved is not to blindly report problems in Fedora bugzilla, but to do the following:
- Consult the known problems list to check if your issue has not been reported before.
- If that is the case, you can increase issue visibility and decrease its resolution time by:
- adding a polite comment in the issue tracker,
- putting yourself in CC,
- voting for the issue when it's possible.
- Otherwise:
- ask help on the SIG list or the ##fonts irc channel to identify what component is likely to cause the issue[4],
- report it directly in the upstream issue tracker of the affected component,
- notify the SIG by CC-ing the SIG bugs list in the upstream issue tracker.
- 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.
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 origin.
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.
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 |