Bug 705975: Fix hires issue with 'v' operator.

The 'v' operator constructs a path segment with the first
control point equal to the current point of the path.

The current PDFI code (ApplyStorePath) implements this in a very
literal fashion; it asks what the current position of the path is,
and then reuses that value.

The problem with this is that we set points into the path
(using, for example, gs_moveto or gs_lineto) and first transforms
the point, then converts it to fixed point for storage.

Calling gs_currentpoint therefore retrieves the fixed point
value, forms the inverse matrix, and transforms it to get us
back to (hopefully) the actual point we were at.

Sadly, in this case, this is giving us a point that when set
back into the path (using gs_curveto) is retransformed and
reconverted to fixed point, giving a value fractionally
different to the original one.

This means that when the path is stroked, we get a very different
tangent vector at the start than we should have done, resulting
in different stroking effects.

While it would be lovely to hope for a system when 'gs_lineto',
'gs_currentpoint', 'gs_lineto' would end up with the same point
in all cases, this is probably unrealistic at such high resolutions
given the nature of floating point operations.

Accordingly, we opt for the simple fix of making 'ApplyStoredPath'
keep track of the currentpoint pre transformation. This solves
the problem nicely.

0 files changed, 0 insertions, 0 deletions