Created attachment 7636 [details] simple.pdf - Vector art of a flower with a spot fill. With the resolution of Bug 692303, TIFF32NC is beautiful now, but TIFFSEP no longer generates spot files (e.g. file.s0.tif, file.s1.tif), even though it logs the spot names to the console. gs -dBATCH -dSAFER -dNOPAUSE -sDEVICE=tiffsep -r72 -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -sOutputFile=simple simple.pdf
This works for me on 64-bit GNU/Linux. The header of the bug report indicated that the bug was happened on Windows 7 but the command line uses 'gs'. Are you running it under Cygwin?
Yup, I'm running under Cygwin. I'd hoped it wouldn't be a confounding factor, as my previous Cygwin build of the source snapshot was able to generate spot files. Sorry for the confusion.
I set up a fresh 32-bit GNU/Linux box, recloned GhostScript from git://git.ghostscript.com/ghostpdl.git, built it, tried again, and got the same result: Outputted files include: simple, simple.Cyan.tif, simple.Black.tif, simple.Magenta.tif, simple.Yellow.tif, but no simple.s0.tif, despite the following output: Page 1 %%SeparationName: PANTONE 211 C Alex, can you verify that you were able to generate a .s0.tif file from the latest master?
The problem is reproduced on 32-bit Linux. The the same revision works fine on 64-bit Linus.
FWIW, I can confirm that I can successfully produce a spot color file under 64-bit GNU/Linux. On a personal note, I'm thrilled to have antialiased spots.
The problem is caused by incorrect value of ARCH_SIZEOF_COLOR_INDEX generated by genarch.c on 32-bit platforms. This happens because a compiler flag that defines it is not passed to genarch. The flag is not passed in 64-bit mode either but we are lucky that the default is correct. I'd suggest to generate all such constants in the configure script but fixing the arguments of genarch may be easier to do.
We may want to amplify the comment, or even produce a warning if separations are skipped during tiffsep when the number of colorants exceeds what we can represent given the current color index size. The documentation in doc/Devices.htm#TIFF _does_ mention the limitation, but the current device operation is probably confusing since the tiffsep device printed "%%SeparationName: PANTONE 211 C" but didn't warn that the separation was not being rendered due to color index limitations. A more expressive warning would be nice, at least for the case where the SeparationOrder and SeparationColorNames are not specified (implying the user isn't pre-selecting a subset of separations).
Somehow when I changed the component to Graphics Library, from 'Vectors' (which was wrong) it unassigned Chris. Changing to Build Process is probably better, but after the genarch issue is addressed, this can be assigned to someone else to add a better message to tiffsep in the case where we skip a separation due to color index limitation. (which I might go ahead and fix in the meantime).
*** Bug 689799 has been marked as a duplicate of this bug. ***
*** Bug 690881 has been marked as a duplicate of this bug. ***
fixed in commit: e5a37634a8e15a945e7f5ea4aca68ab8e1e34d3a Also, added the warning that Ray recommended. See: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e5a376