Bug 692318 - tiffsep device no longer generates spot files.
Summary: tiffsep device no longer generates spot files.
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: master
Hardware: PC Windows 7
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
: 689799 690881 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-06-30 11:42 UTC by Adam Augusta
Modified: 2011-07-06 12:41 UTC (History)
4 users (show)

See Also:
Customer:
Word Size: ---


Attachments
simple.pdf - Vector art of a flower with a spot fill. (577.46 KB, application/pdf)
2011-06-30 11:42 UTC, Adam Augusta
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Augusta 2011-06-30 11:42:49 UTC
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
Comment 1 Alex Cherepanov 2011-06-30 12:30:50 UTC
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?
Comment 2 Adam Augusta 2011-06-30 13:26:17 UTC
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.
Comment 3 Adam Augusta 2011-06-30 21:37:08 UTC
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?
Comment 4 Alex Cherepanov 2011-07-01 04:38:20 UTC
The problem is reproduced on 32-bit Linux.
The the same revision works fine on 64-bit Linus.
Comment 5 Adam Augusta 2011-07-01 15:13:08 UTC
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.
Comment 6 Alex Cherepanov 2011-07-03 00:54:47 UTC
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.
Comment 7 Ray Johnston 2011-07-03 01:13:06 UTC
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).
Comment 8 Ray Johnston 2011-07-03 18:25:25 UTC
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).
Comment 9 Alex Cherepanov 2011-07-04 04:22:14 UTC
*** Bug 689799 has been marked as a duplicate of this bug. ***
Comment 10 Alex Cherepanov 2011-07-05 00:06:01 UTC
*** Bug 690881 has been marked as a duplicate of this bug. ***
Comment 11 Chris Liddell (chrisl) 2011-07-06 12:41:42 UTC
fixed in commit: e5a37634a8e15a945e7f5ea4aca68ab8e1e34d3a

Also, added the warning that Ray recommended.

See:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e5a376