From the customers email: GS 9.00 renders hair lines and other fine objects from the pdf in the attached PDF much finer than the Acrobat as can be seen in the tif files. It seems that Acrobat's minimal object size is at least 2*2 pixel. We often get complaints from our customers for this behavior of GS. gswin32c.exe -sDEVICE=tiffg4 -r600 -o hairline_ghostscript.tif hairline.pdf Adobe Acrobat 9 Pro 9.0.4: Save As -> TIFF (Colorspace: Monochrome, Resolution: 600 dpi)
Created attachment 7077 [details] patch Change all "/foo /bar load def" into "/foo {bar} bind 0 get def" in PDF interpreter to enable operator redefinition with -dDELAYBIND. The file uses "0.12 w", which at 600 dpi corresponds to 1 pixel line thickness. The following command forces minimal line thickness to 0.15 (in the user coordinate system) and renders closer to Acrobat. gswin32c -r600 -sDEVICE=tiffg4 -o out.tif -dDELAYBIND -c "/setlinewidth {.15 .max setlinewidth} .bind def .bindnow" -f foo.pdf
Robin should probably review this one.
The patch enables PS operator redefinition in PDF interpreter for a few common PS operators. By itself it doesn't affect rendering. The command line is a work-around that works for a particular file or a class of files but is likely to produce undesirable results in a general case.
My postscript skills aren't up to Alexes high standard. I understand the intent of what he's doing (from his description), and the patch therefore looks plausible. I therefore think it would be a good idea to commit it.
I meant to ask: Alex, might there be any potential speed issues causes by the late binding of these operators?
Without -dDELAYBIND the patch has no external effects. PDF operators /m , /l, etc. get defined to the corresponding PS operators (not executable names or arrays). With -dDELAYBIND the redefined operators remain executable names and get looked up on the dictionary stack. This is the desired effect that enables various hacks and tricks.
Looks like Alex committed this as revision 11986, so closing. Credit to Alex.