[cairo] PDF Backend for cairo

[Keith Packard]

Around 19 o'clock on Nov 29, Ross McFarland wrote:

> i think it would be best to output correct (best effort) ps/pdf/svg and
> leave it to the interpreters to show it correctly. 

That depends on the intended use of the resulting file.  As a printer meta 
file format, it hardly matters what representation we use, and the fact 
that postscript (and PDF, by association) is known to have a broken 
specification for stroked splines encourages us to provide 'better' output 
via the cairo algorithms.  This leaves us with three (no, four) levels:

	1) High level paths, stroked and filled.  Generates compact and
	   comprehensible PDF/PS, but the results with stroked paths are
	   "less desirable".

	2) Filled polygons.  Perform stroking and spline decomposition in
	   cairo and assume the backend can reasonably fill a complex 
	   polygon.  This relies on the backend managing self intersecting
	   polygons correctly, which is "hard", but at least reasonably 
	   well understood.  For filled paths which include splines, we
	   might well be able to pass these through to the backend, but
	   strokes are not so easy to manage.

	3) Trapezoids.  Use cairo all the way through tesselation.  This
	   is somewhat larger than the filled polygons, but reduces the
	   requirements for correctness in the backend dramatically.
	   Render and OpenGL both support this level and none higher.

	4) Pixmaps.  Use cairo and libpixman to generate alpha masks.
	   Necessary for backends which don't provide known usable
	   simple polygons.

	5) Images.  Pull background image out of destination, draw with
	   cairo and libpixmap and push the resulting image back into the
	   image.

I'd like to avoid providing a huge amount of configuration here, but it 
may be that we really do want to use the highest level available for PDF 
and SVG at times.  But, leaving things up to the backend interpreter will
cause significant visual errors in the output across different backends; 
cairo tries to ensure that those kinds of errors are minimized.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20041129/29a9a81f/attachment.pgp