Re: [Gnome-print] About merging RGBA

[Miguel de Icaza <miguel helixcode com>]

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

Oh so this is like the little "state" system that I implemented for
the preview?  Beautiful.

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

This would be great Lauris.

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

Thanks for the explanation.  This seems trivial to add.

The only reason for that in the Meta driver was that I thought "It is
inneficient to update the size of the metafile on every call, lets
just not allow it to be used until it is finished".

So it should be trivial to fix.  So let me see if I got this right:
you just want the ability of replaying an open metafile, right?

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

OH MY GOD  OH MY GOD.   OH MY GOD.  

I WANT THAT.

*breathe* *breathe*  *pant* *pant*

Ok, lets be calm here.  I want that.

Miguel.