Created attachment 10731 [details] Make pngmono halftone rather than threshold Using the cal.pdf from bug #695078, I noticed that pngmono output lacked any of the gray markings. Devices.htm could be read as to suggest that is intentional, but the pngmonod device isn’t built by default nor by any dist I’ve been able to check (via gs -h|grep png). (The makefiles seem to try to include it, but if so fail.) I used: :; gs -dBATCH -dNOPAUSE -sDEVICE=pngmono -r600 -sOutputFile=calpdf-m600.png cal.pdf expecting printer-level dpi halftoned output, but got threshold instead. Pngmono is the only 1bit output format I tested which isn’t halftoned. I tried both 9.10 and master. If this is intentional, the documentation needs to mention it in the section on png output. Is pngmono’s prn_device_body()’s 3, 4, 1, 1, 2, 2, png_print_page correct? Shouldn’t that start with 1,1 for a gray device (and 3,4 for rgb)? Changing that from 3,4 to 1,1 does cause pngmono to halftone. A patch to that effect is attached.
This is a bug. Both the pngmono and pngmonod devices halftone, the difference is that the pngmono device uses an ordered halftone vs. an error diffusion dither for pngmonod. And in fact the pngmono device works as intended for lower resolutions (i.e. -r100). The cutoff appears to be 150 DPI, below that the output is correct, at or above it's not. Also, it's a regression, before 10de1e0bf9f3abd9c74401258388067c6e2ec36f all resolutions worked correctly.
Yes, commit 10de1e0bf9f3abd9c74401258388067c6e2ec36f is the one which added the line: 3, 4, 1, 1, 2, 2, png_print_page), Which seems to be a cut-n-paste error from the png16 device.
The patch looks fine, committed: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=685e801f Thanks, and sorry for the mistake.