|
XPS renders with the "pixel centres covered" rule, rather than the
"any part of a pixel" rule. As such fill_adjust is 0. This exposes
limitations in ghostscripts pattern tile handling code.
When we come to create a pattern tile, if the pattern is (for instance)
7.5x7.5 device pixels in size, we round this to the nearest integer
and end up with an 8x8 pattern tile. For PS/PDF (which has a non zero
fill_adjust) the pattern will still cause the entire range of pattern
pixels to be drawn.
With XPS (and it's 0 fill_adjust) the patterns frequently leave gaps
around the edge of the enlarged tile, resulting in white lines in the
final image.
My first attempt at a fix for this was to scale the pattern up by
the appropriate amount to ensure it filled the pattern tile (8/7.5
in the example). This works, but causes thousands of diffs; having
examined them all in a bmpcmp, it feels like a win, to me.
However, consulting with Tor and Michael and checking the XPS spec
leads me to believe that that we shouldn't be using TilingType 1
anyway; xps patterns are supposed to be accurately positioned (if not
accurately rendered). As such we should be using TilingType 2.
The patch here therefore forces XPS to use TilingType 2. This does not
solve the problem in itself, as we can still get these white lines.
Furthermore the definition of what TilingType 2 does in postscript
prohibits us from scaling the pattern cell.
The solution adopted here, therefore, is to spot that we are using
TilingType 2, and a fill adjust of 0, and to translate the pattern
by half the change in size; this should ensure that 'edge to edge'
pattern cells should cover all the pixel centres appropriate and
the white lines should disappear.
This appears to work except for one disappearing grid in Page 2 of
tests_private/xps/xpsfts-a4/fts_01xx.xps.ppmraw.72.0. I will look
into this before pushing this commit.
|
