With the following command line on windows: gs\debugbin\gswin32c.exe -sDEVICE=tiffgray -o out.tif -sCompression=g4 gs/examples/tiger.eps We get the error message: Unrecoverable error: undefined in .putdeviceprops. When we'd like something like: "tiffgray: Incompatible Compression method selected". Using -sCompression=lzw works fine (as you would expect). Similarly, using pcl: main\debugobj\pcl6.exe -sDEVICE=tiffgray -o out.tif -r600 -dDownScaleFactor=3 -sCompression=g4 SpoolJob.00000017.PRT produces screenfulls of: tiffgray: Compression algorithm does not support random access. which is very confusing. Again using lzw works fine.
The second problem (lots repeated output from libtiff) only occurs for pcl, not for ghostscript. They are using the exact same put_params code in gdevtifs.c, which calls gx_default_put_params which in turn calls param_commit. For ghostscript, the commit procedure of the param list is set to ref_param_read_commit, which correctly throws an error when one of its parameters has signaled an error. For pcl, however, c_param_read_commit is called, which is empty and always returns success. I don't think tiff's put_params function is wrong here, as it signals errors in parameters just like every other device. I don't understand the relationship between pcl and gs enough to figure out why different commit functions are called and why errors are ignored for pcl. Can someone shed a little light on this for me, please?
(In reply to comment #1) > The second problem (lots repeated output from libtiff) only occurs for pcl, not > for ghostscript. They are using the exact same put_params code in gdevtifs.c, > which calls gx_default_put_params which in turn calls param_commit. > > For ghostscript, the commit procedure of the param list is set to > ref_param_read_commit, which correctly throws an error when one of its > parameters has signaled an error. For pcl, however, c_param_read_commit is > called, which is empty and always returns success. > > I don't think tiff's put_params function is wrong here, as it signals errors in > parameters just like every other device. > > I don't understand the relationship between pcl and gs enough to figure out why > different commit functions are called and why errors are ignored for pcl. Can > someone shed a little light on this for me, please? I just ran pcl on a mac and got: ./pcl6 -sDEVICE=tiffgray -o out.tif -r600 -dDownScaleFactor=3 -sCompression=g4 ~/Downloads/SpoolJob.00000017.PRT Unrecoverable error: undefined in .putdeviceprops Program exited with code 0377. So this is something from the windows build?
> So this is something from the windows build? I can also reproduce this on Linux.
Not sure what is going on with this one. Is there something I need to do with this bug? PCL6 seems to do the same thing as GS (see comment #2). I wasn't sure if Lars meant he was able to reproduce the repeating "random access" messages on Linux or his output was the same as the Mac. Is this still reproducible on Windows?
Assigning back to reporter for clarification (see Comment #4).
A potted history of this bug: When using a tiff output device, if we specify an illegal compression mode, gs gives a cryptic unhelpful error message, and pcl spews lots of (different) unhelpful error messages to the screen (which bury the single useful error message). I've tested today using HEAD and I get the same results on windows, linux and macosx. I cannot explain why Henry gets the same results for gs and pcl on his Mac. In any event, I've found the problems. Firstly, the problem of spewing error messages; it seems that the tiff device does not respond to error codes passed out by the tiff library, it just ignores them and carries on. If I modify the code to respect these values, we get the single helpful error message and then drop out. Secondly, gs uses a different parameter handling api than pcl does, and it fails (with an obscure error message) due to it detecting that compression before it gets as far as generating the page. A simple workaround is to add a warning message to the device at the point where the error is detected. I'll attach a patch that does both these things in a moment.
Created attachment 7097 [details] patch Simple patch to fix the bug.
Assigning back to larsu for his blessing.
Committed as revision 12022 so it can be tested before the next release. If Lars objects, then we can revisit it.