[gs-bugs] [Bug 691923] Differences in dithered output with ps2write

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Mon Feb 7 10:54:23 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691923

Ken Sharp <ken.sharp at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Ken Sharp <ken.sharp at artifex.com> 2011-02-07 10:54:22 UTC ---
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.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list