Created attachment 8352 [details] bad raster pattern PCL raster patterns do not work properly with high level devices. With pdfwrite flat colors are displayed instead of the patterns. Rendering to a raster device like ppmraw produces output that matches the HP.
The 3rd and 4th raster bar are demonstrations of pattern transparency, we know that will not work even when the patterns are properly rendered.
Created attachment 8369 [details] raster pattern Reduced test file with one pattern.
This turns out to be (basically) due to the fact that these are handled in a ROP-specific manner. The 'pattern' is extracted from the 'rop' device by the graphics library and pdfwrite doesn't have any code for this. Re-assigning to Henry to see what happens if we determine this is safe to handle as a non-rop operation and if this can be deterrmined in the PCL interpreter.
Marking LATER, we don't really have any good ideas on what to do about this.
(In reply to comment #0) > Created an attachment (id=8352) [details] > bad raster pattern > > PCL raster patterns do not work properly with high level devices. With > pdfwrite flat colors are displayed instead of the patterns. Rendering to a > raster device like ppmraw produces output that matches the HP. I don't know if pxlcolor is classified as high-level or low, but these two files are improved by attachment 8598 [details] (bug 690585) also.
Since gx_default_strip_copy_rop() supposedly works when destination is not involved, and this is the case for the two files here (at least for pxl - see 690585#c12) and uses only 0xfc(TSo), may be invoking gx_default_strip_copy_rop() on some combination of input parameters would render these two files correctly, at the expenses of large output file size?
See last comment.
*** Bug 695980 has been marked as a duplicate of this bug. ***