[cairo] Scaling tolerance in metasurface playback

[Carl Worth]

On Wed, 31 Oct 2007 15:28:11 -0400, Behdad Esfahbod wrote:
> I've had this patch in my tree for over a year.  Trying to merge it
> finally.

We've had this patch in cairo for over two months. Trying to review it
finally.

(Many thanks to Adrian for pinning me down at LCA to look at this.)

> In short, when meta-surface is playing back to fallback images, it
> doesn't scale tolerance to match device-scale.  As a result, playback to
> a high-res image uses a very fine tolerance (much finer than the one
> intended by the user),

This "intended by the user" is the sticking point I think. The
documentation of set_tolerance says:

	@tolerance: the tolerance, in device units (typically pixels)

And that's not actually all that clear. For a PostScript device, is
this in device-space units of 1/72 inch? or is this in the actual
device-space dots (1/300 - 1/1200 inch or so)? More on this below.

> and playing back to a low-res image uses a very coarse tolerance
> that shows even in the low-res image.

This part of the justification of the patch I don't understand at
all. The change doesn't make anything any less coarse that I can see,
for example. Instead, the change makes the flattening of curves much
more coarse when using a high-resolution fallback image. And that
seems particularly bad. We don't want to make things look worse.

I think the patch could be justified by interpreting the units of the
tolerance value to be the 1/72 device-space units. But I don't think
that's a useful interpretation at all. Our choice of using 1/72 inch
for the device-space of the various printing backends is fairly
arbitrary---following it for tolerance here doesn't lead to any
improvement in output quality. And as seen in the original patch, it
leads to extremely low-quality curve flattening in fallback images
even when using a high-resolution fallback image. Yuck.

Meanwhile, looking at the documentation of setflat in the PostScript
specification it is specified as being in terms of "output device
pixels". And that's an interpretation that leads to high-quality
output.

So I'm in favor of reverting the patch, and clarifying that the pixels
referred to by cairo_set_tolerance are the actual "device pixels" not
just the abstract "device-space units".

One last point with respect to user intent. For native path output,
the tolerance value really has no effect currently[*]---cairo isn't doing
any flattening at all. So the only time the tolerance value comes into
play is when we're dealing with fallback images. And since the
tolerance value is naturally defined in terms of pixels, what better
pixels to use than the actual pixels of our fallback image?

[*] Meanwhile, Adrian points out to me that we're not emitting setflat
at all, (because we can't convert from points to output-device pixels
without being able to query the PostScript device's resolution). But
if we redefine tolerance in terms of output-device pixels as described
above, then we can actually emit setflat.

> Anyone see any reason not to merge it?

Anyone see any reason not to revert it?

;-)

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080130/ff52149b/attachment.pgp