127520 - Large pictures print corrupted

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect, P1)

Description

[Roland Mainz]

Printing the example URL (a large JPEG) ends in a corrupted printout.

Reproducible: Always
Steps to Reproduce:
1. Go to the example URL
2. print it
3. it prints the image in "pieces"

Config:
2002-02-23-08-trunk build on Solaris 7 SPARC, both my hacked version and the
Solaris 7 Xprt show the same problem.

----

First I thought the xlibrgb image tiling code was somehow enabled - but it
isn't. This seems to be a completly new issue. Adding some debugging output
confirms that there is only _one_ |XPutImage()| send to the Xprt server - but
the resulting output shows three Im24 instructions (the first two matches are
from the prolog):
-- snip --
% cat Xpjob_020224073511 | fgrep Im24
/Im24{gs 6 4 r tr scl 8 [3 i 0 0 5 i 0 0]{cf str3 rh p} f 3 ci}bd/Im1t{6
 4 r tr scl t [3 i 0 0 5 i 0 0]{} im}bd/Im24t{gs 6 4 r tr scl 8 [3 i 0 0
253 253 829 315 2961 1125 Im24
253 568 829 315 2961 1125 Im24
253 883 829 3 2961 11 Im24
-- snip --

Comment 1

[Roland Mainz]

Attachment: GIF image generated from PostScript job (ignore the wrong colors, that's a sdtimage bug)

Comment 2

[Roland Mainz]

Looking at xc/lib/X11/PutImage.c - there is some code which splits-up a putimage
request into multiple subimages (see |PutSubImage()| in xc/lib/X11/PutImage.c).
Maybe this is the source of the problem - the image gets split to fit into one 
X protocol request but |PutImageRequest()| does not adjust for the difference
between image resolution and display resolution... xx@@@!!!... ;-(

Comment 3

[Roland Mainz]

Taking...

Comment 4

[Roland Mainz]

Fix in bug 127657...

Comment 5

[Roland Mainz]

Patch for bug 127657 has been checked in... this should be fixed now.

Marking bug as FIXED.

Comment 6

[Roland Mainz]

Fun... this bug is still there (looks that the patch only) ...

Testcases:
- http://www.google.com/technology/pigeonrank.html
- http://www.foreverbrandy.com/paparazzi/01.php

Reopening...

Comment 7

[Roland Mainz]

s/looks that the patch only/looks that the patch only was only a partial fix/

Comment 8

[Roland Mainz]

Attachment: Patch for 2002-04-09-08-trunk

Fix is to reduce the amount of data used for one image. The original fix worked
but not in all cases because there is a small range of size values which may
trigger both our own splitting code and the code in xc/lib/X11/PutImage.c,
too... ;-(

Comment 9

[Daniel Brooks [:db48x]]

Comment on attachment 78712 [details] [diff] [review]
Patch for 2002-04-09-08-trunk

r=db48x

Comment 10

[Marc Attinasi]

Comment on attachment 78712 [details] [diff] [review]
Patch for 2002-04-09-08-trunk

sr=attinasi, but I have to say, gawd that is ugly ;) the numeric (vs. symbolic)
integer constants are ugly, and the shifting is ugly... I know, some people
like that kind of thing, but not me. Anyway, looks like it should work despite
my asthetic complaints.

Comment 11

[Roland Mainz]

The code is mainly based on the code in PutImage.c - and I did not try to modify
it in style, I only adjusted the part which is used to calculate the maximum
amount of data send over the wire before we need to split the image to avoid
exceeding the maximum X protcol request size.
My own code does the same - but I have to a use lower maximum to avoid that the
code in PutImage.c tries to do it's own splitting, too (the first patch worked
but there is a small amount of size values where both codes are running) ...

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 78712 [details] [diff] [review]
Patch for 2002-04-09-08-trunk

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 13

[Roland Mainz]

Checked in by smontagu:

"trunk":
http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1018911180&maxdate=1018911480&who=smontagu%25netscape.com

"1.0-branch":
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_0_0_BRANCH&branchtype=match&dir=&file=&filetype=match&who=smontagu%25netscape.com&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1018910440&maxdate=1018918740&cvsroot=%2Fcvsroot

Marking bug as FIXED.

Comment 14

[Asa Dotzler [:asa]]

adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it
was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify
the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword
with verified1.0.0.

Comment 15

[Roland Mainz]

katakai:
Can you verify for both "trunk" and "1.0-branch" (see asa's comment #17), please
?