This page collects some thoughts in preparation to a cross-distro point on the FLOSS desktop font state.
[[TableOfContents([maxdepth] )
Facilitate feedback
Currently DejaVu, fontconfig and HarfBuzz share a common bugzilla (bugs.freedesktop.org). It would be great if the other components influencing font rendering (other major FLOSS fonts, freetype, pango) would join this bugzilla to help reassign problem reports when needed.
Put an end the pixel/angle of view confusion
Discussion
Some years ago when screens sporting different resolutions started appearing on the market the question of how various hardware pixel densities should be handled was first posed.
The W3C in its great wisdom then redefined pixel as an angle of view, so page designers would not have to worry about screen differences. The GNOME folks followed suit, stating their "DPI" control in font properties was not the real hardware DPI but some sort of abstraction (and they needn't bother about its relationship to the actual hardware used).
Anyone who has changed the resolution of his screen knows this is all fluff. App writers do not use angle of vision but real hardware pixels, so changing resolution has a zooming effect (the screen physical size does not change, nor the user position, so a font expressed in vision angle should have the same physical size before and after the resolution change). Developers only remember the W3C pretend-pixels when asked to configure the hardware properly. The current situation is so confusing the two main DEs do not interpret font sizes the same way.
You'll note that printing something on 300, 600, 1200, 2400 dpi printers do not change the physical text size, just the rendering quality.
CRT-to-LCD migration has stalled screen density improvements for some time, but many laptops already boast higher than 100 dpi resolutions and the situation will change fast once Vista with its scalable UI ships.
Rendering quality (pixel density) and zooming (user-visible font size) must be de-correlated
Proposed changes
- GUI should use different units for virtual pixels (angles of vision) and hardware pixels
- system hardware DPI should be properly configured in Xorg either via DCC or by putting the real displaysize in xorg.conf (using system-config-display and friends). This is a local-system hardware-dependant user-independant setting
- a zoom factor must be applied for stuff like projectors. Again this is a local-system hardware-dependant user-independant setting
- another zoom factor must be applied to take into account user preferences (big or small fonts in the GUI). This is a system-independant hardware-independant user-dependant setting (think multihead, nfs homes, etc)
(maybe first zoom could be merged with hardware DPI as every projector has a recommended distance use)
Combining baseline DPI with the two zoom factors gives you the font scaling to use.
- get monitor size info in hwdata so setup is less painful while bad DCC monitors are still a sizeable minority
Consolidate font selectors
Discussion
FLOSS apps all use different font selectors, having a single control would make user life easier
Proposed changes
- have firefox/thunderbird/seamonkey OO.o GNOME and KDE use a common font selector (with common size units not pt in some cases and pixels in others)
- this selector should link to the char map so users have an idea of the font coverage (hinted glyphs should be marked as hinting is a good info on font quality)
- its UI should help distinguish between actual fonts and virtual fonts (fontconfig substitution groups)
- portland stuff?
Font aliasing & substitution
What are the consequences of font aliasing ?
- if we choose out own FLOSS fonts they're almost certain to have different metrics than the Microsoft one, so OO.o will urgently need a "fit section on X pages" option
- other impacts on paper docs?
- even worse with font aliasing as the substituted fonts won't always be the same and won't all have the same metrics
- font selector UI should help distinguish between actual fonts and virtual fonts (fontconfig substitution groups)
New and enhanced fontconfig aliases
- since the fontconfig default aliases are latin-oriented, should we create families corresponding to classifications in other parts of the world?
- what about other western classifications like Thibaudeau or Vox-Atypi?
- fontconfig enables selection of whole fonts. But fonts may not be of uniform quality, and they often cover more than one script. fontconfig needs to learn to manipulate glyph ranges within fonts for its aliases
- also several scripts share the same glyphs but disagree on its rendering, so fontconfig aliasing must be made lang-aware
Other stuff
- Cf Ben Laenen's analysis in this message
- Have firefox/thunderbird/seamonkey use the same base size for monospace and sans or serif
- define a standard FLOSS font designer toolset, and make sure it's available in all major distros
- anotate fonts in fontconfig to tell the system which dpi values they're optimized for
- prioritize fontconfig aliases : FLOSS fonts with FLOSS toolset first, then FLOSS fonts needing closed apps to change, then closed fonts