Reporting, verifying and getting fixed text rendering issues
Text rendering ecosystem
Modern text rendering is a complex process that involves many componentsCite error: Closing </ref>
missing for <ref>
tag,
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[1].
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 |
- ↑ 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.