Created attachment 7184 [details] screenshot.png Many (perhaps all) of the regression files show a decrease in quality in dithered cmyk (pkmraw) output when processed via ps2write (see the attached screenshot.png for an example, the image on the left is via ps2write and the one on the right is direct to bitmap). The command lines I'm using: ./bin/gs -o test.ps -sDEVICE=ps2write ./PDF_1.7_FTS/fts_32_3239.pdf ./bin/gs -o test.pkm -sDEVICE=pkmraw -r300 ./test.ps
This does not appear to be an actual bug in ps2write. The ps2write device always writes out the halftone at the start of the PostScript output. The default for this is a 106 lpi 45 degree line screen, defined in gs_init.ps. In the absence of any further halftone (and the PDF file does not contain any halftones) this is what gets written to the output. It appears that the pkmraw device is using a *different* default halftone, possibly one based on the resolution of the output. This seems to be set after the initial one, and therefore overrides it. If there is no further halftone set, then this is what gets used for the output, and is the output on the right of the PNG file. If, however, the job contains a halftone, then this is what is used. Since the output from ps2write contains halftone information this seems to override whatever the pkmraw device is setting as a default, and leads to the output seen on the left of the PNG. For PostScript input I can run a file which sets the screen, and this is reflected in the output of ps2write. For PDF input however it looks like an initgraphics (or similar) is performed at the start of the job, which resets the halftone to the default, and so the output PS file again gets set with the default screen. I'll look at suppressing the initial halftone, to see if this can be done without preventing real halftones from being emitted.
OK, there's little I can do about this. pdfwrite, by default, does *not* preserve halftone changes in the output PDF file. If you want that then you need to set PreserveHalftoneInfo to true. ps2write on the other hand *does* preserve halftone changes. The PDF interpreter seems to set the Default halftone if we execute an ExtGState which does not have a halftone entry. This causes pdfwrite/ps2write to record a change in the halftone, so there's no way I can tell that the 'current' screen is the default. I can tell its the same as the default, but I can't tell that the original PDF file didn't contain that halftone. In order to get the same rendered result from ps2write as an original PDF file then we need to set PreserveHalftoneInfo to false. However if the PDF file actually *does* contain Halftone information, then the result will still not be the same. This is also true for pdfwrite; if used to convert a PDF file containing halftones and the rendered output of the pdfwrite PDF file is compared to the rendered output of the original file then the two will be different. I suggest that we alter the default setting of PreserveHalftoneInfo in ps2write from true to false. This matches pdfwrite and since halftone screens are device-dependent I think it makes more sense to discard them unless specifically instructed to preserve them.
Just a stray comment about halftones (I'm sure Ken knows this, just putting it here for others that may consult the bugs for help)... In the real world of PostScript, many PS files set halftone (screen/colorscreen) in ways that may be undesirable for a printer. That's why most PS printers that want to preserve image quality (true of most color laser printers) will use: << HalftoneMode 1 >> setuserparams This allows the printer manufacturer to 'lock in' the halftone so they won't get unpredictable colors due to a particular file's screening (which can drastically affect the color correction). A file that wants to 'take over', can still set the HalftoneMode to 0 before setting their screen (presumably also their CRD), but this is not done by most printer drivers or applications that spew PostScript. Unfortunately, this is a LL3 userparam, so while Ghostscript can handle it without a problem, a PS Level 2 interpreter/printer won't take it.
Fixed in revision 12288: http://ghostscript.com/pipermail/gs-cvs/2011-March/012481.html In setpagedevice, if the device parameter /HighLevelDevice is present and true then we don't call .setdefaulthalftone. This prevents the default halftone (106 lpi 45 degree line screen) being written to the output file. This should mean that the output file does not contain an overriding halftone, and we should us the same halftone as the original file, which should there fore render the same.