Created attachment 7382 [details] Two different patterns on a read backgound i) setdash in a pattern definition leaves a white line (should be transparent) ii) thin white lines outlining pattern elements (reported before) Open the attached pdf file in Adobe of Foxit Reader. None of the above is shown. Open the same in GSview. White artifacts are shown around the black dots on the red background. The PostScript file used to create the pdf (with ps2pdf) is also attached. It contains two patterns defining 45 degrees black dot screens.
Created attachment 7383 [details] Two different patterns on a read backgound
The problem is not shown when using gswin32 directly. Sorry also for the mistyping; the title should be ...on a red background.
Using the current HEAD revision of Ghostscript I can't see any problems rendering the PDF file at 96 dpi, 300 dpi or 600 dpi. Without a Ghostscript command line to reproduce the problem, there's not really much else I can say. I do see the problem when using GSView, so I'm re-assigning to Ghostgum as a GSView problem. It may well be a GS bug, but we need the GS invocation to reproduce the problem.
I *think* GSView always uses GrahicsAlphaBits and TextAlphaBits, so these could be anti-aliasing artifacts.
(In reply to comment #4) > I *think* GSView always uses GrahicsAlphaBits and TextAlphaBits, so these could > be anti-aliasing artifacts. You are correct, setting -dGraphicsAlphaBits=4 reproduces the problem at any resolution. Now, I wonder who gets that ?....
Pattern tiles (apparently) have an image tile and a mask plane. To correctly do antialiasing (and transparency), they should really carry an image plane and an alpha plane. This is a non-trivial engineering task, so will need to scheduled after more urgent work.
Fixed in http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=262c866a71d08c1709484d95ffb3639f53156078 The antialiasing code reduces its buffers and then calls 'copy_alpha' to copy them onto the background with appropriate blending. Unfortunately, the existing implementation deals with alphas of zero by simply sending the existing background colour unchanged. While this is fine in many cases, it has the effect of making any device that watches what pixels are written think that that pixel is 'solid' rather than 'completely empty'. The pattern tile device is one such example; it keeps a mask bitmap of which pixels are written to, and hence gives bad results when pixels are copy_alpha's with 0 alpha values. I have fixed this in the above commit by detecting a 0 alpha value, and 'skipping' it. This is clearly an improvement, but it's not ideal as it leaves 'halos' around objects. The only way to fix this would be a much more invasive rewrite of the antialiasing code (possibly requiring a 'copy_color_with_alpha' device routine). For now, this will do.