Created attachment 7271 [details] simpler.pcl On windows, using the display device on files with rops in gives incorrect results. For example: main/obj/pcl6.exe -sDEVICE=display simple.pcl I first noticed this using -sDEVICE=display -dDisplayFormat=16#20101 to try and reproduce what I saw using -sDEVICE=pbmraw and then loading it into xli on linux. On windows, debug and release builds are different (but both wrong). Attached is a cut down pcl file that shows the problem: Esc * v 1 N Source Transparency = Opaque Esc * l 17 0 Rop13 = 17
(In reply to comment #0) > Created an attachment (id=7271) [details] > simpler.pcl > > On windows, using the display device on files with rops in gives incorrect > results. For example: > > main/obj/pcl6.exe -sDEVICE=display simple.pcl > > I first noticed this using -sDEVICE=display -dDisplayFormat=16#20101 to try and > reproduce what I saw using -sDEVICE=pbmraw and then loading it into xli on > linux. > > On windows, debug and release builds are different (but both wrong). > > Attached is a cut down pcl file that shows the problem: > > Esc * v 1 N Source Transparency = Opaque > Esc * l 17 0 Rop13 = 17 I guess I'll have to start windows and whip out my display device decoder ring. Darn.
Still digging but, FWIW, the problem is of little practical interest, it is an obscure test case where the color space in the image and the color space in the graphics state are different, 8 bit gray and 24 bit rgb, respectively. The default rop is (S|T) results in combining a gray source with an rgb texture, this is never seen in real world files. Guessing ahead I bet the banding code just sets the color space in the graphics state based on the color space in the image.
It is quite common )for PS and PDF, anyway) for the image colorspace to be different than the imager state/graphics state colorspace, and this is handled in both the banding and non-banding image handling. This will require more digging.
(In reply to comment #2) > Still digging but, FWIW, the problem is of little practical interest, it is an > obscure test case where the color space in the image and the color space in the > graphics state are different, 8 bit gray and 24 bit rgb, respectively. The > default rop is (S|T) results in combining a gray source with an rgb texture, > this is never seen in real world files. Guessing ahead I bet the banding code > just sets the color space in the graphics state based on the color space in the > image. Woops! this comment is for a different bug, 691870. Regarding Comment #3, this is to do with CombineWithColor see the gsiparam.h, It think the behavior for non banding and banding is consistent for pdf and postscript with respect to image and graphic's state color space.
Probably worth stating that I've tried 3 different rop values in here, none of which work. I was hoping to pin the problem down to "It doesn't read D back from the device correctly", but even rops that don't use D fail.
I think the following is likely to fix it, it does pass the regression tests. I'll look more Monday. As usual, the code is way too complicated and needs careful study. Index: base/gdevdgbr.c =================================================================== --- base/gdevdgbr.c (revision 12196) +++ base/gdevdgbr.c (working copy) @@ -686,8 +686,9 @@ tdev.height = 1; tdev.line_ptrs = &tdev.base; tdev.base = data; - code = (*dev_proc(&mem_mono_device, copy_mono)) - ((gx_device *) & tdev, row, prect->p.x * depth, + tdev.raster = bitmap_raster(width_bits); + code = (*dev_proc(&mem_mono_device, copy_mono)) + ((gx_device *) & tdev, params->data[0], prect->p.x * depth, min_raster, gx_no_bitmap_id, 0, 0, width_bits, 1, (gx_color_index) 0, (gx_color_index) 1); params->data[0] = data;
Fixed in 12236 well at least for -sDEVICE=display -dDisplayFormat=16#20101. The default display format doesn't work properly yet because it uses BGR (LittleEndian) as a default, which is incompatible with raster operations that expect RGB. The default for PCL should be "DISPLAY_BIGENDIAN" (0<<16) gdevdsp.h:109.