[cairo] Scaling tolerance in metasurface playback

[Behdad Esfahbod]

For the record, Carl and I agreed to revert the commit for 1.6, but
continue discussion later.

behdad

On Wed, 2008-01-30 at 19:01 -0800, Carl Worth wrote:
> 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
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759