[cairo] PDF Backend for cairo

[Ross McFarland]

On Tue, 2004-11-30 at 22:10, Kristian Høgsberg wrote:
> Ross McFarland wrote:
> ...
> 
> > pretty much the conclusion i came to. i got bogged down and spent
> > several sessions trying to fix the transparency/tessilation problems and
> > never got around to doing anything else with my backend.
> 
> What kind of problems did you run into, more specifically?

http://www.neces.com/cairo/basket.pdf
take a look at that file in a pdf viewer that supports alpha. the
problem is the boundaries between tessilated traps. they overlaps ever
so slightly and since that leaves two regions of the same color that are
some amount transparent they add up to more of that color than should
be. different pdf viewers seemed to have slightly different overlaps so
i don't think this is something that can be fixed in cairo or the
backend. to me this is why the route your proposed (passing the draw
commands through to the backend) is probably the only real solution,
anything else and you're going to run into things like this.

a side note my pdf backend work is also in that directory if you want to
take a look at what i did for alpha (etc.) it's kinda messy b/c i was
trying 50 different things to fix the above problem with no luck.

> >>where [ gstate ] means that the current line cap, line join, line width, 
> >>fill rule etc should be passed to the backend.  I'm not sure what the 
> >>best approach would be: either just pass the relevant part of the state 
> >>in the call or let the backend query the gstate object directly. 
> >>cairo_gstate_t isn't exposed to the backends elsewhere, so I'm thinking 
> >>that's not a good idea.  The cairo core would call these functions 
> >>before tesselating and if they return other than CAIRO_STATUS_SUCCESS, 
> >>cairo falls through to the cairo tesselator.  This is basically how the 
> >>other backend hooks work.
> > 
> > the graphics state would be somewhat tricky since both cairo and pdf
> > have them and they would to some degree need to be kept in sync for the
> > above to work well.
> 
> I don't see this as a big problem, the pdf backend could just keep a 
> copy of the current state and update the bits that have changed.  Or it 
> could just set the entire state every time, which still would be saving 
> space compared to putting the tesselator output in the PDF.

agreed.

later,
-- 
-rm
http://www.neces.com/