Bug 692853

Summary: raster patterns wrong
Product: GhostPCL Reporter: Henry Stiles <henry.stiles>
Component: PDF WriterAssignee: Henry Stiles <henry.stiles>
Status: RESOLVED LATER    
Severity: normal CC: ken.sharp, norbert.janssen
Priority: P4    
Version: unspecified   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: raster pattern

Description Henry Stiles 2012-02-12 18:54:41 UTC
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.
Comment 1 Henry Stiles 2012-02-12 19:01:23 UTC
The 3rd and 4th raster bar are demonstrations of pattern transparency, we know that will not work even when the patterns are properly rendered.
Comment 2 Henry Stiles 2012-02-20 22:31:44 UTC
Created attachment 8369 [details]
raster pattern

Reduced test file with one pattern.
Comment 3 Ken Sharp 2012-02-25 01:30:00 UTC
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.
Comment 4 Henry Stiles 2012-06-06 17:01:52 UTC
Marking LATER, we don't really have any good ideas on what to do about this.
Comment 5 Hin-Tak Leung 2012-06-07 18:20:17 UTC
(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.
Comment 6 Hin-Tak Leung 2012-06-09 06:23:03 UTC
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?
Comment 7 Hin-Tak Leung 2012-06-09 06:24:14 UTC
See last comment.
Comment 8 Henry Stiles 2015-05-08 07:59:05 UTC
*** Bug 695980 has been marked as a duplicate of this bug. ***