[cairo] PDF Backend for cairo
cworth at cworth.org
Wed Dec 1 07:26:09 PST 2004
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
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
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
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).
More information about the cairo