Created attachment 7140 [details] Source Post Script file Using the switches: -sDEVICE=tiffpack -r1016x1016 -dNOPAUSE -dBATCH Ghostscript v8.54 converts the attached postscript file 0000_BLK.PS to BLK0000_V8_54.TIF However, I cannot read this file using LIBTIFF v3.9.4; I get the error: "TIFFReadDirectory: Warning, C:\Temp\Ps_to_Tiff_data\BL30000.TIF: unknown field with tag 292 (0x124) encountered." When I use Ghostscript v9.00 I can successfully read the TIFF file but the graphics in the output file BLK0000_V9_00.TIF are corrupted (there are white pixels in what should be solid black areas. Is there a solution to this?
Created attachment 7141 [details] Good Output file This is the good output
Created attachment 7142 [details] Bad Output This is the problem output
8.54 is very elderly (4 years old), so we won't do anything about that. The problem with the 9.0 and HEAD) output is that it is halftoned. The job sets the colour using RGB components (R=G=B=0 = black), the colour management seems to be converting this to 'something else' internally. When rendered to an RGB output device the resulting TIFF file has R=34, G=30, B=31 (according to Photoshop), where I would expect all components to be 0. Passing to the colour expert for further investigation.
In fact, the rendering from ghostscript 9.02 is correct or at least matches what AR and distiller do to the file. To compare, apply Acrobat distiller, open with AR and save as tiff monochrome. Note that the letters are halftoned. If you want to avoid this, you will need to specify different ICC profiles. The current output is correct given the default ICC profiles that are used. The fills that you have in the file are filling with CMYK value of [0 0 0 100%]. For most CMYK devices and in particular for the default SWOP CMYK color this is NOT the blackest point. So, when we end up going to a monochrome output device we end up mapping to something that is NOT that device's blackest point. Adobe does the same thing. To alter this behavior, you want to define how you would like CMYK values to be interpreted as well as the characteristics of the output device profile. For example, if you include -sDefaultCMYKProfile=ps_cmyk.icc this profile will end up mapping a CMYK value of [0 0 0 100%] to the blackest point for your output device. In that case, you will see 100% K on the monochrome device. You may also want to considerusing -sOutputICCProfile=ps_gray.icc for your monochrome device profile. Marking bug as invalid since it is really not a bug but simply the proper settings need to be made to get the desired output.