Re: GTK+-2.x planning

[Keith Packard <keithp keithp com>]

Around 17 o'clock on Mar 12, Havoc Pennington wrote:

> One thing I've been meaning to bring up is printing. Right now we basically
> have that on the someday-maybe 3.x timescale - which is 2004 or most likely
> later. I think a stopgap would be valuable if we can come up with something
> meaningful, perhaps just a virtual GdkDrawable. But I don't know what the
> range of options would really be, what would be involved, or who we have
> who could work on it.

The hardest part of printing is selecting fonts.  Without a single 
consistent mechanism for accessing fonts that works for both display and 
printing, any printed output is going to disappoint.  Further, printed 
output must include the fonts by default to eliminate printer dependencies.

That means any font access mechanism must provide access to the glyph 
outlines so that they can be passed to the print driver; either for 
embedding as Type3 or Type42 outlines in Postscript or for suitable 
rasterization for bitmap printers.

Qt uses precisely this mechanism and output with that toolkit is very 
consistent.  It's not "great", because the underlying rendering model for 
text isn't very sophisticated, but at least it looks just like the 
document does on the screen.  For the naïve user, having the printed 
output appear precisely as it does on the screen is a huge win, even if 
what appears on the screen isn't perfect.

The trouble that Qt has is in locating the outlines for fonts accessed 
through the core X protocol.  It goes through tremendous effort to locate 
the appropriate files, even grubbing through the font server configuration 
file to locate the font server font path.  Even then, it doesn't expose 
the scalable metrics to applications; this significantly constrains the 
precision with which applications can position glyphs on the page.

I suggest that Gtk+ and Pango should abandon the core X fonts and focus on
client-side font support.  This means that printing can always use 
precisely the same fonts as display, and that the display can use all
of the information available in the outline font file for accurate 
placement and selection of glyphs.

> One more suggestion here is the "trivial shaper" people can use to
> implement terminals, fixed-cell-width text widgets, and cross-platform
> wrapper toolkits like SWT/AWT that want to see an X-style font API.

I suggest that Gtk+ provide an interface to parallel the current font/
fontset APIs for client-side fonts.  I've done this and ported xchat with 
only cosmetic modifications to the code.  The only issue is with locales 
and character sets; Xft lives in a Unicode world, so Gtk+ may need to 
provide some transcoding abilities.

I don't believe we need to preserve any Xlib/Xft abstractions -- there's 
no reason to continue using core X fonts in any Gtk+ application, and 
several good reasons to abandon them.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab