[cairo] Re: On recovery from errors in cairo (was: cairo reset)

Mike Emmel mike.emmel at gmail.com
Fri Sep 22 12:32:43 PDT 2006

On 9/22/06, Carl Worth <cworth at cworth.org> wrote:
> On Fri, 22 Sep 2006 11:34:29 -0700, "Mike Emmel" wrote:
> > I posted a patch for this already it has more problems then this.
> I'll go take a look at the patch soon, (as I recently said, I was
> buried in the tessellator when it first came by). And I'll wait to ask
> you to clarify "more problems" until after I've done that.
> > I can understand wanting to know if the user has never set a path and
> > we know that.
> Right, that sounds like the functionality that's currently missing in
> cairo.
> > I disagree that a line to results in a move to if no point is set it should
> > do a line to from 00 to the point its a lineto not a move to.
> That's one we're not free to change now. The behavior Behdad described
> is documented, released, and relied upon by existing programs. (Not to
> mention, that I still like the rationale I originally used for this).
> In PostScript, lineto not preceded by moveto is an error, (hey, look!
> we actually did avoid placing cairo into an error state on at least
> one occasion). I cannot imagine any situation in which (0,0) will be a
> necessarily interesting point for starting a path.
> I do understand that drawing something that's "wrong" in an obvious
> way might make it easier to debug than setting an error. But, we don't
> have an error in this case, we instead have the line_to implicitly
> convert to a move_to. The motivation for this is to allow for code
> which can loop over an array of points to set up a polygonal path:
>         for (i = 0; i < num_points; i++)
>             cairo_line_to (cr, points[i].x, points[i].y);
> rather than having to special-case the first point:
>         for (i = 0; i < num_points; i++)
>             if (i == 0)
>                 cairo_move_to (cr, points[i].x, points[i].y);
>             else
>                 cairo_line_to (cr, points[i].x, points[i].y);
> Of course, the special-casing approach still _works_ just fine. I just
> thought it would be kinder to allow the simpler approach above by
> defining reasonable behavior instead of an error state.
> -Carl

I think we need to determine how many angles can exist on a head of a
pin first :)

If we can reliably determine that we don't have a current point then
the current behavior
is probably okay. Then the user can guard if he wants to.
I think its cleaner to always start at zero both conceptually and in the code.
Then the whole concept of no current point goes away.
But I also like square headed pins :)


More information about the cairo mailing list