[cairo] Cairo is non-deterministic?

[Dirk Schönberger]

> > moveto (0, 1)
> > for (int i=0; i<10; i++)
> > {
> >   rotate(360/10)
> >   lineto (0, 1)
> > }

> That kind of thing will work fine in cairo. And this is a great
> example of what I called a "path-creating function" above.

> Imagine you wanted to take something like the chunk of code above and
> put it into a function called make_regular_polygon which accepted the
> number of sides. The caller of make_regular_polygon likely does not
> want to see any change to the CTM by calling this function. The most
> natural way to do that would be to surround the implementation of the
> function body with a save/restore pair.

> But if the path were part of the gstate, then this save/restore pair
> would also prevent the path modification from being visible to the
> caller. So the function would have no effect. In that case, to get the
> desired result, the implementation of the path-creating function would
> have to avoid calling save/restore and would instead have to manually
> save and restore individual elements of the graphics state (CTM,
> source pattern, etc.) which would be tedious and error prone.

It depends. If I had to do this with a pure Postscript model, I think I
could circumvent the problem by separating path creation and path rendering.
I.e. something like

void create_star (int numsides)
{
  moveto (0, 1)
   for (int i=0; i<numsides; i++)
  {
    rotate(360/numsides)
     lineto (0, 1)
   }
}

void fill_and_stroke_path ()
{
  gsave
  fill
  grestore
  stroke
}

gsave
create_star (10)
fill_and_stroke_path
grestore

> The fact that the path is _not_ part of the gstate allows
> cairo_save/cairo_restore to be used within a path-creating function.

While I respect your decision, I am still not quite convinced why this is
needed ;)

> Yes, similarity with the "standard" models established by PostScript
> and PDF has been an explicit goal in the design of cairo's API. In the
> case of "is the path saved as part of the gstate?" it turns out that
> PostScript and PDF don't agree, so there's no immediately obvious
> "standard" solution.

Ok. Understood.

Regards
Dirk