[cairo] Paths as paths

[Owen Taylor]

Currently, backends only have access to paths after they are turned into
trapezoids. This has some very noticeably downsides for the PDF backend:
the generated output files are huge, resolution dependent, and tend to
have seams on some PDF viewers.

The attached patch adds a new virtual function fill_path() to the
surface backend interface. If it returns UNSUPPORTED then the current
logic is run. And then implements a fill_path() for the PDF backend.

I had a PDF file with about 300 words rendered as text as path.
 From memory, the numbers were approximately:

  Before: 40 meg file, killed acroread, xpdf took 2 minutes to
          render, consuming 200 megs of memory
  After: 2 meg file, acroread, xpdf rendered instantly

(Maybe it killed xpdf and acroread took 2 minutes to render, not
sure at this point.)

To keep the patch from touching every single backend, I made NULL
for fill_path be equivalent to UNSUPPORTED ... this is actually 
something I'd like to see implemented uniformly across all backend
functions.

I think for paths this approach is pretty obviously better than what we
are doing currently. But what about strokes? The same problems above
apply.

Approaches:

  1. Let the backend intercept stroke() in the same way as path(),
     write strokes as strokes to PDF files (and so forth).
     Consider problems with the rasterization of wide, sharply
     turning stroked lines to be a quality-of-implementation
     issue.

     Pro: Produces the smallest and most natural resulting files

     Pro: Produces resolution independent files

     Con: many elements from the gstate affect stroke, so we'd have
          to pass the gstate to the stroke_path() function or
          have a ton of parameters.

     Con: while "quality of implementation issue" is fine for
          viewing, it's a less satisfactory answer for if we are
          writing to an intermediate file for printing.

          We have the theoretical ability to fix ghostscript when
          we are using that as a RIP, but practically speaking that
          may not be easy. And no ability to fix postscript
          rasterizers in printing.

  2. Convert strokes to paths, pass the path to the backend

     Pro: We get to use our own stroking algorithm

     Pro: All the gstate dependence is gone by the time the
          backend gets involved

     Con: Files are not resolution independent (assuming that
          the stroke-to-path algorithm produces polygonal paths,
          which I think is what is planned.)

     Con: Files are larger, possibly much larger (again assuming
          that we have a polygonal path)

Perhaps some sort of hybrid approach is right. We could actually
try to detect paths that will produce problems with stroking
algorithms that convert curve => polygon before stroking and emit
those strokes as paths.

Anyways, I don't think we need to block on fixing strokes to fix
paths.

Regards,
					Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cairo-path.patch
Type: text/x-patch
Size: 6073 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050305/060e747c/cairo-path.bin