[cairo] get-clip-svg-* test failures

[Robert O'Callahan]

On Fri, 2006-09-29 at 16:07 -0700, Carl Worth wrote:
> The problem is that the test suite assumes that the backend will
> always be able to provide the clip as a list of rectangles if the user
> passes in a list of rectangles.

Actually the test checks the surface type and tries to avoid that
assumption for surface types that we know don't support it: currently
PS, PDF and SVG. Bryce's log shows we actually succeed on PS (and
doesn't test PDF), and I'm pretty sure SVG also worked in my tests. I'll
have to check up on this when I'm back in the office.

> So there is a question to answer before knowing the right way to fix
> this:
> 
>     What guarantee do we want cairo_copy_clip_rectangles to make? Can
>     it return CLIP_NOT_REPRESENTABLE arbitrarily?

That's a good question.

> If so, then we just need to make the get-clip test case less strict
> and just declare the test a SUCCESS when it get a NOT_REPRESENTABLE
> status value back.

I favour using the relaxed postcondition that CLIP_NOT_REPRESENTABLE can
be returned anytime, but we could still have the test structured as it
is now, to expect stricter results than advertised for situations where
we think a rectangle list should be returned.

> Otherwise, we would need to fix copy_clip_rectangles to try a bit
> harder. For example, in the current failing case, we've got a path
> representing one or more rectangles, so it wouldn't actually be that
> hard to convert that to the form the user wants back.

In this case, how would you then write the
cairo_copy_clip_rectangle_list postcondition to describe the situations
under which we promise to return an actual rectangle list? Seems to me
it would have to be something complex like
"We promise to return a rectangle list when the paths used to set the
current clip were all created as a sequence of cairo_rectangle calls
only, and the tranformed rectangles all mapped precisely to device-space
coordinates. Otherwise we may return CLIP_NOT_REPRESENTABLE."

> Oh, but there's another huge ambiguity in the current documentation
> for cairo_copy_clip_rectangles. Does it guarantee that the rectangles
> it returns are non-intersecting? Or does it only guarantee that the
> intersection of the rectangles is the same as the clip region, (and if
> so, with which fill rule?).

You mean "the union". I think we should add to the docs that the
rectangles are non-intersecting.

Rob