Re: [Gnome-print] About merging RGBA

[Lauris Kaplinski <lauris ariman ee>]

On 18 May 2000, Miguel de Icaza wrote:

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

OK. Maybe Chema can look once more into Red Book, and suggest which
meaningful errors from there should be defined.

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

It is basically state holding structure for serialized graphic commands.
It is trivial, except that:
- it is stack, so you can push/pop contexts
- contexts hold 2 vector paths (clip and graphic paths)

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

Once I implemented a rouch variant of it. The main problem was that X
does not handle multipart vector paths :( - so I had to XOR all subpaths
sequentially into bitmap first. I'll do it again, if nobody has better
solution.

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

GnomePrintFRGBA is example of group context. It is created, using one
"real" context (PostScript usually) and then creates itself GnomePrintMeta
context. Then it performs all graphic methods on both of these contexts.

Now, if semitransparent shape should be filled, it:
- creates temporary bitmap buffer
- creates GnomePrintRBuf context drawing to that buffer
- asks its GnomePrintMeta subcontext (containing all drawing from the
  start of page to that point) to replay itself into rbuf context
- clips buffer and sends it as rgbimage to "real" context
(like shape would be filled with bitmap, showing correct image of
 underlying graphics)

The problem is, that at moment GnomePrintMeta do not want to replay
itself before it is closed. Currently I use separate GnomePrintFMem
context for that, but meta does almost the same, so maintaining different
context is certainly overkill.

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

P.S. CanvasBpath CAN be clipped in latest rgba CVS :)

Regards,
Lauris