Re: [Gnome-print] About merging RGBA

[Miguel de Icaza <miguel helixcode com>]

> 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.

I think they return the number of bytes written, and -1 for errors.

This convention does not really make sense, it made sense for say
Postscript to return something interesting, but I agree, it is not
really good right now.

I suggest we use 0 for success, and we use negative values for
indicating those errors you mentioned in your mail message.

> 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...

It sounds good.  Although I am not sure what it does yet, but you are
the expert.

> Abandon GnomeCanvasBpathDef - GPPath is a bit more powerful:
> - it has shorter name :)

heh.

> - it can be decomposed into closed (fillable) and open parts

OH MY GOD.  Does this mean that we can actually generate polygons that
we can feed into X11's broken XFillPolygon?  This is awesome!

Because this means we can have a non-AA bezier path item :-)

> - 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)

I am all for it, all for it.

As you pointed out, lets just wait for 1.2 to go out.

> 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.

I do not understand the question, but if you explain it to me in more
detail, I can help.

> 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.

Beautiful.

> Implement GnomePrintRGBP as group class, rendering job page-by-page into
> GnomePrintMeta, and replaying it into band-sized GnomePrintBuf during
> showpage.

Can you explain this to me in more detail?  I did not understand what
you are proposing here at all.

What do you mean by "Group class".  Why do we want to render pages
into GnomePrintMetas?  

Remember, we do drive the process at a higher level using
GnomePrintMetas.  Would we use another GnomePrintMeta at a lower
level?

> 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

Beautiful :-).  I just hope I could understand the above ;-)

> 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

It does not matter if they are broken, fixing them should be simple.

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

Beautiful.

Miguel.