Created attachment 3195 [details]
RFW22.zip

zip file containing the customer's PCL file.

customer priority.

I'll need to take some time to unravel this one.  Apparently the user started
with a large raster that comprises the characters on the page.  Parts of the
raster were missing and the user attempts to correct the missing parts by
painting black rectangles over the missing parts of the image.  The placement
requires precise alignment of the rectangle and raster.  I will start working on
it after the next release (mid august), in the mean time I have made it bountiable.

Created attachment 3860 [details]
simplified test

This is a simplified test case for visualizing the problem described in #3. The
rectangle has been changed to red while the raster remains black.

Created attachment 3869 [details]
rectangle postscript bug

This bug seems to be related to a problem with our rectfill operator.  The
postscript example, rect_test.ps, prints a rectangle on page 1 with rectfill
and page 2 prints what should be the same rectangle (according to PLRM) using
fill.  The rectangle on page 1 fills 1159 <= y <= 1287, page 2 fills 1160 <= y
<= 1287.

gs -r600 -sDEVICE=ppmraw -sOutputFile=rect_test%d.ppm rect_test.ps

Temporarily assigning to Leo to have a look at the path problem.

The following patch to HEAD fixes the Postscript problem with attachment 3869 [details] :

http://ghostscript.com/pipermail/gs-cvs/2008-March/008199.html

Unfortunately this patch doesn't help to pcl6 - white stripes still appear. 
While tracing pcl6 I can see fill_tectangle is called at once while rendering 
the attachment 3860 [details], and the upper function adjust_render_rectangle in pcrect.c 
performs some strange computations with coordinates. Particularly it first 
rounds the rectangle origin then adds a rounded width. IMO it should first add 
then round. Also when the lower boundary of the rectangle falls to pixel 
center, the pixel must not paint by Postscript rule, but it is painted with 
djust_render_rectangle, which may be correct or not for PCL - just don't know. 
Besides that, the computation for "disp" looks incorrect with rotating 
matrices - IMO it should convert {1,0} and {0,1} separately (it's a common 
error for many gs modules). Passing to Henry for further analyzis.

I haven't had a chance to look at this until now.  I still see a problem with
the graphics library fill code.  With the test file "simplified test" there is a
single rectfill, the identity matrix is set.  The rectangle passed to rectfill
has p.y = 1224 and  q.y = 1288.  The rectfill procedure fills scanlines 1225 -
1287.  pcl uses a center of pixel rule fill adjust is 0.

pcl6 -r600 -sDEVICE=ppmraw -sOutputFile=simple.ppm simplified\ test

The x coordinate fill is more reasonable, p.x = 2136 q.x = 2152, the actual
pixels filled are 2136 - 2151, which is what I would expect.

Back to Leo.

Created attachment 4273 [details]
out.ppm.zip

Henry, 
I still can't figure out what the problem is. Attaching the raster I've got
with 600 dpi. Is it same as yours ?

I tried both banded (as yours) and unbanded rendering, both gave *same* result
(a byte to byte comparison says the files are equal).

Command lines : 

..\..\ghostpdl\main\obj\pcl6.exe   -dBATCH -dNOPAUSE  -r600 -sDEVICE=ppmraw
-sOutputFile=outn.ppm simplified_test.pcl
..\..\ghostpdl\main\obj\pcl6.exe -dMaxBitmap=1000000000  -dBATCH -dNOPAUSE 
-r600 -sDEVICE=ppmraw -sOutputFile=outn.ppm simplified_test.pcl

Then I run the unbanded rendering (to exclude the clist stuff) with debugger
and I see 1 call to gx_rectfill with *red* color. The arguments are y=1224
h=64, and it immediately forwards to mem_true24_fill_rectangle.

So what I see is : (1) the color is read, not white, and (2) the filling
algorithm is not involved at all. A manual checking of pixel coordinates and
addresses appears pretty difficult due to macros used in
mem_true24_fill_rectangle, but from my point of view the formula are correct.

When I continue with debugger, I see it paints 6 images. Note it happens
*after* the rectangle is filled with red. 

So I guess a white stripe (or stripes ?) may appear (1) from each image, or (2)
from gaps between images, or (3) from gaps between emages and the rectangle.

Returning to Henry. Please point out what should I analyze next and which
stripe exactly must not appear.

Sorry, probably didn't explain it properly the first time.  I don't think the
red rectangle is rendered correctly.  Putting a breakpoint on rectfill:

Breakpoint 1, gs_rectfill (pgs=0x10ff3b0, pr=0x7fffd4fad0b0, count=1) at
../gs/src/gsdps1.c:187
(gdb) p *pr
$3 = {p = {x = 2136, y = 1224}, q = {x = 2152, y = 1288}}

(identity matrix)

in out.ppm (your attached output image) the y pixel closed interval [1225, 1287]
is painted.  The x interval appears correct in the output image, closed interval
[2136, 2151] is painted.  The y interval has one less pixel than what I would
expect.

Put another way x paints from p.x (2136) to q.x - 1 (2151), y paints from p.y +
1 (1225) to q.y - 1 (1287).  The former is a half-open interval and the latter
is an open interval.

Henry,

I instrumented gxifast.c revision 8250 with inserting "return 1;" at line 632. 
It skips all images in the test document. Running it I get red rectangle at Y=
[1224, 1288]. Removing it back I get red at Y=[1225, 1288]. Thus Y=1224 is 
overprinted with an image. Then I inserted a conditional breakpoint at 
gxifast.c ln 634 with codition iy+dy==1224 and I see that the 5th image does 
paint y=1224 x=[2132, 2132+2868]. It paints through a clipper device with a 
single rectangle : ymin=100 ymax=6500 xmin=100 xmax=5000, so the clipping is 
not relevant. The red rectangle is strongly inside the image rectangle (the 
latter starts at y=1218 and continues over 1232 (I discontinued the tracing of 
the image after y=1232 because I only inrerested about y=1224, so I don't know 
where the image ends exactly)). When mem_true24_copy_mono is called for the 
real rendering that image to the real output device, the zero color is 
gx_no_color_index, so it's an imagemask, and the red rectangle appears in a 
mask's hole except y=1224.

For the further analyzis I need to be sure that the obtained result and the 
possible continuation complies to your wishes.

Please note that in February 2008 I did cnanges to image interpolation code in 
gxidata.c, which works here, but those changes were done 6 months later than 
this bug is open. So they're not relevant. Near the bug opening date Ralph did 
stylistic changes with no change to algorithm. Next older change is 
Stefan "merge from pcl tree", in Oct 2006, which relates to memory management 
only. Skipping some stylistic changes next older change is Jan 2005 by Igor to 
color conversion only. So I think it's not a graphics library regression.

Returning to Henry for further directions, because all this is very time 
consuming, and the goal is still unclear. Can you bring a reference 
implementation that proves that we're render incorrectly ? 

completely my fault, my diagnosis was incorrect.  I thought the rectangle was
being rendered too small when in fact it is being overwritten.  We do have an HP
reference that paints the job without the white gap, I'll need to redo my analysis.

Created attachment 4350 [details]
simp7.pcl

simp7.pcl demonstrates the landscape presentation mode 3 y origin for raster is
at device y position 6480 (ppmraw 600dpi), the device y origin for a rectangle
(pcl rule) is at 6479.	The hp4600 has the same y origin for both objects.

An outside consultant is working on this one.  We expect completion in the
August 2009 release. 

Created attachment 4770 [details]
pcrect.c

pcrect.c with fix for this problem.  We are in code freeze and the change
cannot be integrated at this time.

fixed in revision 9451.

This fix was not correct.

For 600 dpi these files print correctly with 11898.  To downscale these files the tiffscaled device should be used.