[Gnome-print] About merging RGBA

[Lauris Kaplinski <lauris ariman ee>]

Hello printers!

1. What are gnome print methods supposed to return? Currently it seems,
that 0 is error and 1 is success, but not all contexts/methods do it that
way, and some return -1 for error...
0 (success) / errorcode (error) would be most easy to remember and debug.
Still, if sticking to TRUE (success) / FALSE (error) there should be a
way to get error code back.
Of course, printing errors usually are not very helpful. But still they
could give some idea, especially while debugging.
GNOME_PRINT_OK
GNOME_PRINT_NOCURRENPOINT
GNOME_PRINT_NOCURRENTPATH
GNOME_PRINT_ERROR_IO
GNOME_PRINT_ERROR_PRINTER
etc.

2. I promised to continue with RGBA branch. To merge it into head, I would
like to make following changes:

Add GnomePrintGC object, which implement graphic context stack. This is
immediately usable for GnomePrintPreview and buffer contexts. Probably
also for plotters, if anybody will do such contexts some day...

Abandon GnomeCanvasBpathDef - GPPath is a bit more powerful:
- it has shorter name :)
- it can be decomposed into closed (fillable) and open parts
- it keeps corresponding ArtBpath well-formed
- it has much more convenience methods
As a result, GnomeCanvasBpath internals will be greatly modified, but this
is no-issue. It shouldn't break anything (no serious program can count
on GnomeCanvasBpathDef being available from gnome-print, I hope)

Make GnomePrintMeta to replay unfinished streams. If anybody knows well,
how to do it, I would be pleased. Otherwise I have to figure it out
myself. This shouldn't also break anything.

Add GnomePrintBuf context (RBuf in RGBA branch) which prints into
arbitrary RGBA/RGBA (possibly also grayscale?) buffer. As buffer is
defined as affine-transformed rectangle, it can have whatever
place/size/resolution possible.

Now comes the funny part:

Implement GnomePrintRGBP as group class, rendering job page-by-page into
GnomePrintMeta, and replaying it into band-sized GnomePrintBuf during
showpage.
This has one bad and one good size-effect:
Bad - printing will be slower. Currently canvas caches all vector paths,
so rendering bands should be reasonably fast.
Good - it does not depend on X any more
Extra bonus - it can do RGBA
Classes derived from RGBP should not be broken, as long as they do not
depend neither internals nor assume anything about inheritance

Add GnomePrintFRGBA aka 'Fake RGBA' context, which renders semitransparent
shapes into bitmaps and print those.

If anybody can suggest better ways doing this (rgba and buffer printing)
or knows something which will be broken beyound repair, I would be glad to
hear.

Also, has anybody Red Book handy, and can tell me:
How do fill, eofill, clip and eoclip handle currentpath? Do they close it,
if open? Do they do implicit newpath?
How should fills and clips behave, if asked to fill partially closed,
partially open path?
Does show do implicit newpath? Does it advance currentpoint?

Regards and happy printing
Lauris