The attached .eps shows a 4-corner polygon with a cross-hatch fill. The cross-hatch is shown with -sDEVICE=x11, but not with -sDEVICE=x11 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dMaxBitmap=50000000 or -sDEVICE=tiff24nc. The polygon is always shown. AFPL Ghostscript 8.53 (2005-10-20) Is this a (longer standing) bug, or an unimplemented feature? When converting the .eps to .pdf with gs 8.53 ps2pdf14, both xpdf and acroread show the cross-hatch as expected. gs 8.53 has the same problems with the .pdf as with the .eps.
Created attachment 2085 [details] EPS test file which isn't handled correctly. Cross-hatch fill not shown with x11 device and antialias, or in tiff24nc.
Also see bug #688580
Verified as reported with 8.53. Also apparent with the display device. With SVN head abd the following command line: bin/gswin32c -dGraphicsAlphaBits=4 ../test_files/688588.ps -c quit I get the following: AFPL Ghostscript CVS PRE-RELEASE 8.54 (2005-10-20) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. AFPL Ghostscript CVS PRE-RELEASE 8.54: Unrecoverable error, exit code 255 The error is coming from: c:\_\artifex\gs\src\gxpcmap.c(361): Returning error -100 Which says: return_error(gs_error_Fatal); /* can't happen * Guess the comment is wrong.
We do not currently implement pattern tile accumulation devices with destination alpha. The heart of this work would be implement standard Porter-Duff "over" rules in the copy_alpha method. This may help with this bug, but it looks like the main thing is filling in some unhandled cases.
By turning on the repeated-rendering path of bug #688826, as opposed to the pattern accumulator, we will likely get correct rendering even without implementing porter-duff alpha compositing in the pattern logic.
This appears to have been fixed -- at least it doesn't fail and the output looks reasonable with the command line: gswin32c -dEPSFitPage -dGraphicsAlphaBits=4 -r100 bug_688588.ps