Created attachment 8766 [details] testcase If I display the testcase eps on Windows, everything looks fine. If I try to generate a bitmap i.e. with -sDEVICE=tiff24nc or -sDEVICE=pngalpha, I get a black square. This happens not only on Windows but i.e. on Solaris, too. If I use version 9.04, tiff24nc works but pngalpha crashes. If I use version 8.71, everything is fine.
Ghostscript fails to render some glyph at very small size. The following simple program shows solid cyan screen when it's run as gs foo.ps %! 0 0 moveto 1 0 0 0 setcmykcolor /Helvetica findfont 0.02 scalefont setfont (a/) show showpage
I haven't check the pngalpha seg fault, but tiff24nc generating a black page as output started with: commit 2a3a329ab0ee0e2f4971ee0327ae78d532399619 Author: Chris Liddell <chris.liddell@artifex.com> Date: Fri Nov 4 10:02:38 2011 +0000 Bug 692646: remove bad call to memcmp() The memcmp() to compare the matrices (to decide if we need to rescale the font) was the address of the pointer to the matrix, rather than the pointer itself. This change addresses that by changing the memcmp() to an explicit check for the equality of each element of the arrays. The reason I've opted for this is because, for example, [1 -0 0 1 0 0] == [1 0 0 1 0 0] which an explicit equality check will evaluate correctly, but a memcmp() will fail the check. This causes what seems to be a progression in comparefiles/Bug689006.pdf. Other than that, no cluster differences are expected.
Fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=44b01d27
Oh, and pngalpha crash with 9.04 was because the job results in a degenerate matrix for rendering the glyph ([1 0 0 0 x y] - so scaling by zero in the y dimension, IIRC). The 9.04 FAPI code did not compensate for this, and tried to enumerate a non-existent glyph path. This fix changes how we compensate for such degenerate scaling.