[cairo] Bug in PDF output with independent path/pen transformations

Behdad Esfahbod behdad at behdad.org
Thu Nov 1 10:31:43 PDT 2007


On Thu, 2007-11-01 at 23:44 +1030, Adrian Johnson wrote:
> Behdad Esfahbod wrote:
[snip]
> The PDF and PS references both specify that the implementation limit of
> the smallest nonzero is 1e-38. Anything under that is rounded to zero.
> 
> Reducing the x scale value in the "line at an angle" test in
> degenerate-pen.c shows that Evince and Adobe Reader stop working before
> limits of printing with "%.18f" are reached.
> 
> At the scale (0.000000001, 1.0) Evince produces incorrect output.
> Reducing the x scale by another factor of 10 results in no output.
> 
> The scale (0.00000000000001, 1.0) is the point where Adobe Reader 8
> produces no output. At this scale the matrix values near zero still have
> four significant digits (0.000000000000007071).
> 
> At the scale that Evince breaks the pen width is equal to 1 dot on a
> 72,000,000,000 dpi device. As no device has anywhere near this
> resolution one possible solution is to adjust the matrix to limit the
> minimum dimensions of the pen so that it will produce correct output on
> all devices.

I think the other components in the matrix are relevant too.  That is,
it's the

  x = x1 * m.xx + y1 * m.xy + m.x0

that is underflowing because x1 * m.xx and y1 * m.xy need too many bits
to compute losslessly.

We should make sure that a cairo_scale (1e-20, 1e-20) followed by path
constructs all multiplied by 1e20 works.


> >   - Those are useful for writing out matrices, and we can't get much
> > better at them.  But for path coordinates we can do better, namely, use
> > tolerance.  If tolerance is 0.1, we need not more than two digits after
> > decimal point.  However, we should scale tolerance exactly like in my
> > recent mail about scaled-tolerance in meta-surface.
> > 
> > /me waits for ickle to chip in his part in this bug :-P
>
> I am not seeing why the resolution of the path coordinates should be
> linked to the curve flattening tolerance. They are two separate things.
> A user may increase the curve flattening tolerance for better
> performance but still expect all objects to be accurately positioned
> when imported into another application and rescaled.

Humm, that's not the way I look at tolerance, though now that I read the
docs, you are right.  In my opinion though, tolerance is simply the
error margin acceptable by the user.  If you define it like that, it's
quite acceptable to use it in rounding.

-- 
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





More information about the cairo mailing list