x11 seems to be broken for some pcl cet files, ../gs/base/gdevx.c(916): Returning error -15. A few examples in tests_private/pcl/pcl5ccet/ are 14-07.BIN, 15-01.BIN, 15-03.BIN, and 16-05.BIN.
The X implementation of get_bits_rectangle does not work with the default display on Mac OS X. These files do work on a default linux setup. xdpyinfo on Mac OS X reports a color depth of 15. See comments in the code gdevx.c, near line 863 to see what we can support.
Interesting - this bug seems to depend on the language and the file. I can reproduce this on linux by having a funny Xserver setting, actually. I'll see if I can fix this. I picked a handy pxl file lying around (pxl data from bug 690972 http://bugs.ghostscript.com/attachment.cgi?id=5732&action=view), and it works find at depth 24 but at depth 15 dies with Warning interpreter exited with error code -992 Flushing to end of job PCL XL error Subsystem: KERNEL Error: IllegalAttributeValue Operator: ReadImage Position: 42556 file position of error = 2262303 Which is bogus, I think.
It appears that treating 15 the same as 16 just works (for all the pcl5ccet files), athough unfortunately the pxl file (http://bugs.ghostscript.com/attachment.cgi?id=5732&action=view) behaves differently under 24, 15 and 16. (16 looks like the erroreous pgmraw result, 15 misses also the square below the pgmraw missed square). It is possible to testing different depths with Xvfb and setting DISPLAY on linux.
Created attachment 5748 [details] X11 depth 15 patch Treat depth 15 as depth 16, and updated documentation. pixel data appears to be byte-aligned and the rest of the current code seems to work correctly for depth 15 (or, no worse than depth 16). Also updated documentation on how to switch color depth in Mac OS X to 24, the recommended usage.
I think we could simplify this code dramatically with XGetPixel which normalizes each pixel. What do you think Hin-Tak?
The code would be simplier with XGetPixel(), but it would slow down display and refresh. Assuming XGetPixel() and XGetImage() work at similiar speed per fetch (that would be case over a network) using XGetPixel() and doing a fetch per pixel would make it hundreds of times slower that XGetImage(). That may make X11 unuseable for people where the display is not on the same machine as the one running gs. I don't know how much slower it would be.
I believe XGetImage could be used to retrieve the data and XGetPixel processes the data returned by XGetImage. Isn't that how X11 typically does screen capture?
Oh, sorry, I mis-read the manpage. Yes, it looks best that way. I wonder why lpd didn't do it (it is another piece of very old code again). Maybe XGetPixel wasn't available in older platforms, etc. but yes, could do.
Looked at John Bradley's xv's screen grab code ( which supposedly derives from xwdtopnm (netpnm suite)); it does bit/byte swap internally. It looks like very old X11 software does not use XGetPixel.
patch committed as r10491 , and also added further comment about XGetPixel wth r10623 . The crash is gone with r10491 . Visual artefacts at depth 15/16 noticed in comment 2 is filed as new bug 690998 .