When comparing the output from bitcmyk and tiffsep, I found that tiffsep is handling overprint correctly, the bitcmyk device appears not to. The problem exists in at least 8.11 and 8.50. In the example file the rendering of the blocks saying "Text*" is wrong, and the area with 1%CMY 100%K with overprint is broken
Created attachment 1360 [details] overprint_testpage.noimage
bitcmyk device was "fixed" to work correctly with rops. For CMYK devices we need to resolve that working with rops OR working with overprint are curently mutually exclusive. See improved conversion rule comment in gdevbit.c
If I change the decode_color function in the bit_procs in gdevbit.c from bit_map_color_rgb to NULL, I get a better (though still partly incorrect) result - the problem may lie in there
The problem was caused by the changes made by Stefan for PCL ROPs (raster operations). There is a conflict between what the PCL team wants for proper operation of ROPs (which is always done in an RGB color space) and what is needed for overprinting (which is always done in a subtractive color space). The planned solution to this problem involves make the map_color_rgb device procedure (which is currently depreciated) active again and to use it for ROPs. This can have some ripple effects since the current logic uses the map_color_rgb procedure as a default for decode_color if the former is defined and the later is not. This would not be correct for a CMYK device after this change. If you need a quick fix, then unwind Stefan's change to gdevbmp.c
map_rgb_color map_cmyk_color map_color_rgb seems like the orthogonal map_color_cmyk never existed. decode/encode color lets the device choose the color space returned. Sounds like the solution is that all cmyk or device N devices will need to implement both map_color_rgb and decode_color, then the library caller can choose which behaviour it wants.
From Stefan: >Sounds like the solution is that all cmyk or device N devices will need to >implement both map_color_rgb and decode_color, then the library caller can >choose which behaviour it wants. Yes. However this means that someone has to verify that all of the CMYK devices have the correct procedures.
Created attachment 1390 [details] A simple example showing striping issue When run with the command line gs -sDEVICE=bmpsep1 -r400 -sOutputFile=xx <attachment> This example file shows a striping effect which shouldn't be present, other resolutions/pag-sizes may work. The bitcmyk device is also broken. The bug is present in 8.11, 8.50, 8.51, and CVS head (sunday 15th may) When I've caused similar striping, it's usually by looping over an area with the wrong step size...
>A simple example showing striping issue Is this new problem related to the original report? The original report is about overprinting with the bitcmyk device. Now you are referring to 'stripping'. Please do not combine unrelated issues in a single bug report. Note: Distiller 6.0 gives the following error messages with the new test file. Distill Time: 0 seconds (00:00:00) **** End of Job **** Start Time: Monday, May 16, 2005 at 9:41 AM Source: 688068a.ps Destination: C:\_\artifex\test_files\688068a.pdf Adobe PDF Settings: C:\Documents and Settings\All Users\Documents\Adobe PDF 6.0 \Settings\High Quality(1).joboptions %%[ Error: undefined; OffendingCommand: .setoverprintmode ]%% Stack: 1 %%[ Flushing: rest of job (to end-of-file) will be ignored ]%% %%[ Warning: PostScript error. No PDF file produced. ] %% Distill Time: 0 seconds (00:00:00) **** End of Job ****
>When I've caused similar striping, it's usually by looping over an area with >the wrong step size... I would strongly recommend against creating PS or PDF files in which the 'wrong step size' is an issue. If the file is dependent upon the resolution of the output device, then you are extremely likey to have problems. We receive problem reports on a regular basis which are due to someone doing gradient fills or transparency effects with very thin adjacent rectangles. An example of this sort of problem is 687974 which shows different results with Adobe Acrobat 6.0, Illustrator CS, and Ghostscript.
In answer to Dan's two comments: 1a. The file will fail in distiller as it uses the Ghostscript specific operator ".setoverprintmode" to switch on overprint mode. 1b. I believe that the original test file may demonstrate two bugs, the striping effect is related to switching on overprint at 1 bpp bitdepth in cmyk devices. The bug in which overprint is not honoured correctly may or may not be in the same part of the code, but does fall under the same title. 2. I meant in other image processing applications, not in postscript. The postscript in the 2nd example is very simple. I mentioned stepping as that's what the problem looks like (something like stepping in 32bit ints & only filling in the 1st byte of each). The fact that it's resolution dependent has nothing to do with the postscript & but shows that the algorithm generating the bitmap is probably unstable - maybe has a rounding error.
>1a. The file will fail in distiller as it uses the Ghostscript specific >operator ".setoverprintmode" to switch on overprint mode. I recommend using setoverprintmode (which takes a bool for its input) for this purpose. See TN 5145 for more info. Using operators which are internal to Ghostscript creates a file which is not portable. We may also modify or delete internal operators. >1b. I believe that the original test file may demonstrate two bugs, the >striping effect is related to switching on overprint at 1 bpp bitdepth in >cmyk devices. >The bug in which overprint is not honoured correctly may or may not be in the >same part of the code, but does fall under the same title. There are indeed problems demonstrated by the second test file. These are not limited tot he bitcmyk device. There also are problems with black overprinting which isnot limited to 1 bit devices. I am do not know the cause of either problem. They are probably separate issues from the map_color_rgb changes that Stefan made. For now I am leaving this as one problem report. My guess is that I will split it in two one I know what is happening. Thanks for the new test file.
Bug 688110 has been created to track the striping problem shown in the second test file. See that report for more information on the second problem. Note: These two issues are being split into separate bug reports since they are different issues. This report is being kept for tracking the changes needed for the PCL ROPs versus what is needed for PS/PDF overprint. ROPs are done in an RGB color space. The changes that Stefan made to the bitcmyk device cause it to return RGB values. PS/PDF overprinting requires values in the device process color model, i.e. CMYK for the bitcmyk device. Bug 688110 has been created to track the problem with the striped output when overprinting on a halftoned device. This problem is visible on other halftoned devices besides the bitcmyk device. Note: A quick fix for the overprint issued with the bitcmyk device, can be obtained by backing out the change from Stefan Kemper described in: http://ghostscript.com/pipermail/gs-cvs/2004-June/004566.html
Note: For all devices, except the bitcmyk device, the first test file displays properly after the fix for 688110 ia applied. This fix is described in: http://ghostscript.com/pipermail/gs-cvs/2005-May/005522.html Thus only issue remaining is the general problem of making both ROPs and overprint work for non RGB devices.
Bug 688638 has been added for tracking the changes required for ROP/overprint compatibility.
To complete this bug, the changes made for ROP support in gdevbit.c have been logically removed. Details in: http://ghostscript.com/pipermail/gs-cvs/2006-April/006463.html