gnome-print, pango etc.

[Lauris Kaplinski <lauris ximian com>]

Hello!

Gnome print is slowly taking nice and compact shape for future versions.
What is still completely unsettled, is the exact integration of text
formatting frameworks - thing I'd like to hear your opinions about.

The gnome-print core (driver implementations) use:
- wrappers around FT_Face (GnomeFontFace, GnomeFont, GnomeRFont)
- GnomeGlyphList text representation
Both are completely self-contained, and very probably remain such. What
we have to establish, are connection paths between Pango fonts and
gnome fonts, plus front parts of text formatting pipeline - whether
it happens in gnome-print or some other library.

Font system features
Gnome-print needs full access to original font file(s) in case it has to
embed it into printer job.
Fonts are unencoded - whatever sequence FreeType gives us is passed to
all drivers.
We need font aliasing - i.e. NimbusSans -> Courier.
We are only interested in scalable (Type1 and TTF) fonts.

Currently gnome-print uses it's own font database. The installation
system is relict from ancient times, which I have modified now and then
- but it needs major rewrite anyways.
Still it would be of little interest to maintain separate font
databases, especially as Gtk/Pango is getting involved with client-side
font anyways (XRender)
So, if there will be general client-side font installation system +
database, gnome-print can use that, as long as it fulfills
abovementioned requirements. We can simly either implement GnomeFont as
wrapper around PangoFont, use FT_Face from it, or use file directly.
The alternative would be to maintain gnome-print font database, and 
provide outside interface rich enough, so that we can construct
PangoFonts from GnomeFonts. In that case WYSIWYG document fonts would
remain clearly distinct with other system fonts (X fonts, bitmap only
fonts) - it has both good and bad sides.

GnomeGlyphList
It is hybrid format between text flow, and positioned glyphs. It uses
glyph codes instead of character values, so the final placement can be
determined without any language-specific code. Still, in case glyphs
make natural flows, the relative position is determined by glyph
advancement values, not exact positions - so small resolutions render
more cleanly.

The glyphlist format is immature (and is private to gnome-print for
that reason). Currently we support:

moveto (exact placement)
rmoveto (relative placement)
push (saves pen position)
pop (retrieves pen position)
color (RGB at moment)
font
advance (use LtoR 'classic' advancement rule for following glyphs)
kerning (relative kerning amount 0-100% of maximum)
letterspace (in points)

This is the only format gnome-print internals use. Still I am quite
sure, people would expect more friendly frontend to printing process,
dealing with character strings instead of glyphs.
Current methods are relicts from latin1 times, and will be deprecated.

What is needed, is some Pango implementation (in gnome-print or some
other place), that generates glyphlist from rich text. I am sure, it
would be relatively easy to do, as soon as font hierarchy is resolved.
In worst case, it can simply fall back to positioned glyphs string -
whatever it can do more, is sugar.
Still I am not sure, how the text should be represented, and how much
formatting the frontend(s) should do. AFAIK line-based  formatter is
not enough. So it should probably be paragraph based. But then we have
to deal with page breaks etc.

So, does the overall structure make sense?
Any suggestion of preferred font relations?
Anybody working of Pango formatter suitable for printed output?
etc.

Best wishes,
Lauris Kaplinski