[cairo] PDF Backend for cairo

[Ross McFarland]

On Mon, 2004-11-29 at 14:59, Kristian Høgsberg wrote:

> Right now the PDF backends only render the trapezoids cairo passes it 
> after tesselation.  PDF has the same curve_to and line_to operators as 
> cairo has and could do stroking and filling if it was passed the 
> highlevel path instead of the tesselation output.  I think this could be 
> acheived by adding stroke_path() and fill_path() function pointers to 
> the cairo_surface_backend_t struct, something along these lines:
> 
>      cairo_int_status_t
>      (*stroke_path)              (void                   *dst,
>                                   cairo_surface_t        *src,
>                                   cairo_operator_t       operator,
>                                   int                    xSrc,
>                                   int                    ySrc,
>                                   cairo_path_t           *path,
>                                   [ gstate ]);
> 
>      cairo_int_status_t
>      (*fill_path)                (void                   *dst,
>                                   cairo_surface_t        *src,
>                                   cairo_operator_t       operator,
>                                   int                    xSrc,
>                                   int                    ySrc,
>                                   cairo_path_t           *path,
>                                   [ gstate ]);

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.

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

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