[Gnome-print] Using gnome fonts on gdk

[Lauris Kaplinski <lauris helixcode com>]

Hello!

Until there is solid font API in X, I am hacking together a way to render
gnome fonts directly to gdk drawables. I.e. creating pile of pixmap/mask
pairs and drawing those - so interested parties can start using
full-featured fonts now, and wait for X to catch up...
(there is test implementation in current gnome-print CVS)

This poses cacheing problem:

Glyph pixmaps have to be cached per-display basis, and preferrably
destroyed, if that display is not needed any more - unlike cached RGBA
glyphs, the lifetime of whose should be decided completely by gnome-font
library. We probably do not want font-system to keep caches of pixmaps for
several remote displays, even if corresponding (bonobo) connections have
been closed, but rfont - (being cached object itself) - is still alive.

I see several almost clean API variants for that:
(For the uninitiated - rfont is (in current design) rasterizable font -
i.e. font whose glyph pixel shape is determined - unlike GnomeFont,
whose pixel shape depends on transformation matrix of canvasitem or
printcontext and/or printer's pixel resolution)

1. Create rfonts per-display basis, like
rfont = gnome_font_get_rfont_gdk (font, affine, drawable)
...
gnome_rfont_unref (rfont)

2. Add one more derivative font object, like
rfontgdk = gnome_rfont_get_rfontgdk (rfont, drawable)
...
gnome_rfontgdk_unref (rfontgdk)

3. Add a way to request (font) drawing contexts, like
ctx = gnome_rfont_get_gdk_context (rfont, drawable);
...
gnome_rfont_unref_gdk_context (ctx)

4. Add realize/unrealize calls, like
gnome_rfont_realize (rfont, drawable)
...
gnome_rfont_unrealize (rfont, drawable)

5. Let the rfont cache anything it likes as long as it wants (in normal
cases there is only 1 X display to care of - but it can become a problem
for bonobo component servers)

These are functionally equivalent, as proper pixmap creating context has
to be determined by font system anyway (corresponding root window for
local glyphs, toplevel? window for remote ones).
So the question is - which API is prettiest and will have longest lifetime
(is meaningful even with supremegapowerfulXfontapi).
I do not like 1 & 2, making API more complex (I like the idea, having one
and only rfont for given font + transformation). 2 & 3 are basically the
same (whether we call it font or context - but it makes little difference
in gnome-font library). 4 has pretty method names, but add another hash
table lookup step - although that shouldn't be big penalty, if we are
dealing with X calls anyway.

API really counts, as changing it later will be total headache.

Suggestions? (You are also welcome to suggest to throw the whole project
away)

Regards,
Lauris