[cairo] Sorry I broke the text tests! (and status update)

[Jeff Muizelaar]

On Mon, Feb 19, 2007 at 12:47:04PM -0800, Carl Worth wrote:
> > > > Additionally, I have some rough patches that clean things up even more
> > > > in the dashing-cleanup branch. Assuming the stuff in this branch is
> > > > correct, the dashing code is actually beginning to look better.
> 
> I've just finished up reviewing what was in the dashing-cleanup-4
> branch. The code fixes (and cleanups) look quite good to me---so Jeff,
> I think you'll be able to finish this up and push without any more
> review from me.

Pushed. A big thanks goes to Jeff Smith for making this series of fixes
and cleanups happen.

> Here are the comments I have:
> 
> 1. The 2500-pixel wide image is quite annoying. It's hard to view in
>    the results, and it makes the pdiff code (when it fails) _really_
>    slow, (as in, over 7 minutes just for this one test).
> 
>    Ideally, it'd be nice to just extract the unique things that are
>    being tested here and get them expressed explicitly in the much more
>    minimal degenerate-path case.
> 
>    But if we don't know exactly what the unique things are that this
>    test is hitting, then please, can we at the very least eliminate a
>    *lot* of the black background pixels that are needlessly slowing
>    down the pdiff compare so much?

Done. I cut the image size to about 1/3 of the original.

> 
> 2. The ps result is failing. Part of this looks like a missing
>    ps-specific reference image, (differing antialiasing on the
>    caps). But part is also the difference in the case of
>    to-join-or-not-to-join for a dash that starts precisely at the
>    beginning of a "bend" in the path where a join would go.
> 
>    I know Jeff has wrestled with this case a bit, as the following
>    comment appears in the implementation:
> 
> 	/* This segment ends on a transition to dash_on, compute a new face
> 	 * and add cap for the begining of the next dash_on step.
> 	 *
> 	 * Note: this will create a degenerate cap if this is not the last line
> 	 * in the path. Whether this behaviour is desirable or not is debatable.
> 	 * On one side these degnerate caps can not be reproduced with regular path stroking.
> 	 * On the other side Acroread 7 also produces the degenerate caps. */
> 
>     I'm comfortable with leaving the details of this specific
>     situation as backend-dependent in cairo. That is, I'd be fine with
>     leaving the implementation as is, (throwing in a ps-specific
>     reference image to capture the difference), and not do anything
>     heroic like detecting this case and dropping back to image-surface
>     fallbacks just to make the PS output match the exact rasterization
>     of the image backend.

Done. We have a ps reference image describing the ghostscript
rasterization.

-Jeff