[Cairo] Color transforms
cworth at east.isi.edu
Wed Jul 16 17:26:14 PDT 2003
On Jul 16, Bill Spitzak wrote:
> Converting a path to a stroke outline is actually really complex and maybe
> should be in the device-independent portion.
Yes, it is complex. One nice thing about taking care of tasks like
this in the device-independent piece is that we can have better
guarantees of matching output on different devices, (especially when
some backend devices have shortcomings in their own implementations of
The balancing act is to maintain good performance while generating
high-quality matching output.
> PostScript seems to join the segments with whatever join type the user has
Yes, this is the behavior we've seen from every implementation we've
been able to test. And from reading the description of the flattenpath
operator, this behavior may be mandated by the specification.
It's not hard to construct a test case that exposes the problem with
this approach. The attached file has a single spline stroked with both
a narrow and wide linewidth. The flatness is set to 0.5 which is
defined to make the result correct within 1/2 device pixels. But on
every interpreter I've tried the cusp of the wide spline is incorrect
by several pixels, (4 long straight line segments are noticeable on
> This sounds like the problem can be solved by being able to indicate at each
> point what type of line-join is wanted.
The effect is similar to stroking line segments with round joins, but
Cairo currently has a much more efficient algorithm for stroking
splines than for doing round joins. What occurred to me today is that
the efficient algorithm for spline stroking could probably also be
applied to the case of straight lines with round joins.
> But it also has several other bugs, for instance round joins seem
> to be done by splatting a circle atop the intersection, which is
> visible if the lines are shorter than they are wide.
This one is definitely a bug in the specification. It explicitly
states that the "wrong side" of the circle will show through in these
The algorithm in Cairo avoids both of these bugs, so it shouldn't be
hard to generate correct results on any output device.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 427 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20030716/2b9fadb5/badspline.eps
More information about the cairo