The attached files are rendered differently when converted directly from PostScript to ppmraw vs. PostScript to pxlcolor to ppmraw (see the .png files for reduced size output, the page on the left is the direct conversion). Sending the resulting pxl file to a HP LaserJet P3005 results in a file identical to that produced by GhostPCL, so this is a -sDEVICE=pxlcolor issue. Ghostscript head (r01236) was used for testing. Here are the command lines: gshead -sDEVICE=pxlcolor -r600 -o $1.pxl ./$1 pclhead -sDEVICE=ppmraw -r600 -sOutputFile=$1.viapxl.ppm -dNOPAUSE ./$1.pxl gshead -sDEVICE=ppmraw -r600 -o $1.direct.ppm ./$1
Created attachment 5570 [details] bigpaths.ps
Created attachment 5571 [details] bigpaths.ps.png
Created attachment 5572 [details] colored_pattern.ps
Created attachment 5573 [details] colored_pattern.ps.png
Created attachment 5574 [details] uncolored_pattern.ps
Created attachment 5575 [details] uncolored_pattern.ps.png
Created attachment 5576 [details] 5570 pxl streams clip to max_16bit Actually both of 5571 are wrong - the correct appearance should be 4 different colors to 4 corners of the box. The number oveflows differently on different gs devices. (and different platform also). This is a best attempt (clip the numbers to largest representable), but pcl6 appears to do it wrongly. Does a printer do this pxl stream the same way as pcl6?
Created attachment 5577 [details] clip signed shorts and signed short pairs to (-32768, 32767) clip signed shorts and signed short pairs to (-32768, 32767). The fixes the problem with 5570 somewhat so it is closer than how it should be (the direct ppmraw result in 5571 is actually wrong) but the cursor co-ordinates in PXL is limited to either signed short pairs or short pairs, (i.e. both (-32768, 32767) or both (0, 65535). Maybe one can massage the CTM temporarily to turn a large number into within limit, and massage it back for such ridiculously big paths. need a little time to think.
Comment on attachment 5577 [details] clip signed shorts and signed short pairs to (-32768, 32767) part of the big patch, attachment 5599 [details] (Bug 690858) addresses set cursor 16-bit overflows much more satistfactorily. bigpath.ps should work after that patch.
uncolored_pattern.ps is fixed by the patch in 690830 plus the corrected patch in 688372. the problem with uncolored_pattern.ps is essentially the same as 690025 - it has got both white-on-transparent and black-on-transparent, although one is a star shape and the other is a font glyph.
colored_pattern.ps, although looks completely different, is fixed by the same patch as bug 690862 - to implement data_bit properly in write_image_data().
Argh, the three files has three different sets of problems and basically cover all the problems recently fixed in the pxl driver. bigpaths.ps is a set_cursor co-ordinate overflow, and fixed by r10271 'Use SetPageScale to work around 16-bit limit in SetCursor' (and r10270 'new SetPageScale/Unset utility routine'). It also have negative co-ordiates so r10267 'write signed 16-bit integers' is also relevant). colored_pattern.ps is fixed by r10313, 'handle data_bit'. uncolored_pattern.ps is a white-on-mask and black-on-mask case and fixed by r10305 (and r10303).