one black cell in ppmraw is rendered transparent.
Created attachment 5732 [details] pxl data generated from 468-01.ps with -sDEVICE=pxlmono, r10431 from Marcos. comparing pcl6 -sDEVICE=pgmraw -sOutputFile=... and pcl6 -sDEVICE=ppmraw -sOutputFile=... one of the black cells is rendered transparent in pgmraw. (or one of the transparent cells in pgmraw is rendered black in ppmraw, as the case may be).
Comment on attachment 5732 [details] pxl data derived from 468-01.ps
Created attachment 5733 [details] side by side comparison another file from Marcos - left is how it looks from the original ps, gs->ppmraw and X11, pcl6->ppmraw, middle is pcl6->pgmraw, right high-lights the position of the difference.
Comment on attachment 5733 [details] side by side comparison derived from 468-01.ps
The ppmraw output is correct vs. the HP. Generally pcl requires an RGB process color model to produce completely accurate results, some non rgb devices (wtsimdi) set up an rgb contone buffer exactly for this purpose, unfortunately we do not have that feature for pgmraw or most non rgb devices. So this isn't really a bug, if we had extra cycles, not likely in the immediate future, it would be interesting to explore what exactly goes wrong here.
Anticipating a response to comment #5, 1 bit per pixel monochrome is fine. pbmraw has a black box like ppmraw and unlike pgmraw.
I have a vague idea how this might happen - for most part in the pxl code, tranparent is mapped to all 1's (white in RGB/8-bit gray) and setting the white-is-transparent flag. This works okay when the other color is not white, except when the other color is black. Somehow for a black/white all-0/all-1 combination, what-is-what is inverted somewhere inside ghotscript - 1 means colorred-(black) and 0 means no color (white). Something like this, anyway.