236801 - [ps] Printing the URL above mozilla creates a corrupted PS file

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Marco Arioli]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

When printing the URL this document to a file using Postscript/Default, mozilla
creates a corrupted PS file, so it can't be printed on a PS printer nor viewed
with gv (or ggv). Other pages on that URL have same problems.

Reproducible: Always
Steps to Reproduce:
1. Open the URL.
2. Invoke File -> Print
3. Choose Print to File
4. Choose PostScript/Default as the Printer
5. Press the Print Button
6. Invoke "gv mozilla.ps" from the command line.

Actual Results:  
GV ERROR:
========================================
Error: /undefinedresult in --image--
Operand stack:
   1   1   8   --nostringval--   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1   3  
%oparray_pop   .runexec2   --nostringval--   --nostringval--   --nostringval-- 
 2   %stopped_push   --nostringval--   5   3   %oparray_pop   --nostringval--  
--nostringval--
Dictionary stack:
   --dict:1047/1123(ro)(G)--   --dict:0/20(G)--   --dict:113/200(L)--
Current allocation mode is local
Last OS error: 2
ESP Ghostscript 7.05.6: Unrecoverable error, exit code 1


Expected Results:  
Create an uncorrupted PS file.

Actually I don't know if it's a problem of mozilla or ghostscript. But if I
print the URL with netscape 4.79 the file is OK.

Comment 1

[Andrew Schultz]

not xprint

Comment 2

[Andrew Schultz]

Attachment: testcase

<img src="http://www.repubblica.it/s.gif" width="5" height="1300">

printing with the postscript module generates a .ps file ghostscript refuses to
load.  s.gif is a 1x1 transparent image.  using mozilla-banner.gif instead of
s.gif resulted in a file ghostscript would load.

Comment 3

[Andrew Schultz]

confirmed with linux trunk build 2004031109
also, ghostscript can handle the xprint-generated .ps file.

Comment 4

[Andrew Schultz]

Attachment: postscript output from testcase

Comment 5

[Andrew Schultz]

this regressed between linux trunk builds 2003102305 and 2003102405, pointing to
bug 80190

==> kherron

Comment 6

[Kenneth Herron]

Attachment: Handle clipped images better

The testcase contains a 1x1 pixel scaled to 5x1300 pixels tall. This is too
tall for the page, so the arguments to nsPostScriptObj::draw_image() specify
that only part of the image should be visible. Part of one pixel is zero pixels
so a scaling factor ends up with the value zero, which is invalid.

This is different from bug 191684. There, the destination rectangle, i.e. where
on the page the image should appear, had a dimension of 0. Here the source
rectangle, the portion of the image to print, has a dimension of 0. 

This patch forces source rectangle dimensions to at least 1. I've also added an
additional check that the image data rectangle doesn't have a dimension of
zero.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 143882 [details] [diff] [review]
Handle clipped images better

+  if (!theBits || (0 == iRect.width) || (0 == iRect.height)) {

Could just be

if (!theBits || iRect.IsEmpty())

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Would be nice to fix this regression for beta

Comment 9

[chris hofmann]

Comment on attachment 143882 [details] [diff] [review]
Handle clipped images better

a=chofmann for 1.7b

Comment 10

[Kenneth Herron]

Checked in:

Checking in nsPostScriptObj.cpp;
/cvsroot/mozilla/gfx/src/ps/nsPostScriptObj.cpp,v  <--  nsPostScriptObj.cpp
new revision: 1.112; previous revision: 1.111
done

I decided not to use |nsRect::IsEmpty()| because it tests for dimension <= 0
rather than dimension == 0. This code generally treats rectangle heights and
widths as vectors; negative values are legal. iRect is just the image rectangle
so it may be that height and width are never negative, but the code in the patch
is known to work so I thought it best to stick with that.

Resolving FIXED.

Comment 11

[Kenneth Herron]

*** Bug 246399 has been marked as a duplicate of this bug. ***