[cairo] PDF Backend for cairo

[Carl Worth]

On Wed, 01 Dec 2004 07:49:09 -0500, Ross McFarland wrote:
> i don't know that i tried filling after drawing all of the traps. i
> guess i didn't make the assumption that all of the traps i'll be getting
> are overlapping (one solid object.)

When the user calls cairo_stroke or cairo_fill the current path is
filled as a "single object". I say single object in the sense that the
region covered by the entire fill/stroke is composited as a whole
against the background. The regions covered by the path need not be
contiguous. Indeed, the path may consist of many subpaths covering
disjoint regions. But, even if some subpaths overlap the "single object"
rule means that there can be no visible evidence of the overlap in the
result.

That path (or region) is the input to the tessellator. The output of the
tessellator is a set of disjoint trapezoids whose union is the region.

>                                     what will happen with complex
> self-crossing objects like the five point star and such. i think the
> traps you get there won't necessarily make one solid region to fill, but
> several smaller ones.

Sure, but complex fill rules are dealt with entirely by the
tessellator. By the time the backend gets a set of trapezoids all it has
to do is display these simple primitive polygons.

Ah! And I could see what your concern was if you didn't know that the
tessellator always produces non-overlapping trapezoids. Since it does,
there's no need to worry about fill rules.

So there are only a few details that are important to get right in the
backend:

1) The tessellator carefully produces non-overlapping trapezoids. This
   means the backend must not move any edges or else seams may result,
   (eg. computing new intersections is bad). However, the current
   10-number trapezoid specification makes the requirement infeasible for
   some backends, (glitz and PDF). The new tessellator currently in
   progress will provide a 6-number trapezoid which won't require
   intersection.

2) The backend rendering must satisfy the sum-to-one invariant for
   trapezoids that tessellate a device pixel, (eg. don't introduce
   seams). The current spline stroker generates some "hard" cases for
   this such as a triangle fans for round joins. The new tessellator
   will make this much easier as it will output long trapezoidal spans
   with pixel-aligned top and bottom edges.

3) The summed coverage from the trapezoids must be pre-computed before
   the result is composited against the background. That is, each
   trapezoid must not be incrementally composited, but instead the group
   must be summed and the result composited. For an opaque path, using a
   single fill operation in the PDF backend satisfies this
   constraint. For a translucent object, it may be necessary to also use
   a transparency group, (but perhaps not).

-Carl