226600 - [ps] Print Preview overwrites printed file

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Klaus-J. Wolf]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4.1) Gecko/20031015
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4.1) Gecko/20031015

Having printed to a file before, selecting print preview overwrites the recently
created file.

In my tests, the overwritten file always has a length of 33749 bytes, no matter
what page has been print-previewed. The file does not contain any displayable
content.

Reproducible: Always

Steps to Reproduce:
1. print to file
2. select print preview
3. display the file

Actual Results:  
The file appears to have no content.

Expected Results:  
The file should have the content that has been printed in step 1.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this using XPrint or PostScript printing?

Comment 2

[Klaus-J. Wolf]

Postscript.

Comment 3

[Jesiah S]

I see this on LInux 2003120506
I also notice that moz zeros the file during print preview and then saves a
blank file when you close print preview.

Comment 4

[Kenneth Herron]

Confirming. During print preview, an nsPostScriptObj is initialized with the
settings from the last print job. If the last job was a print to file,
nsPostScriptObj opens the final destination file for writing and writes the
boilerplate postscript header to it. This results in a valid postscript file
that doesn't actually print any pages.

Comment 5

[Kenneth Herron]

nsIDeviceContextSpecFactory::CreateDeviceContextSpec() creates the device
context spec for the print job. One of the arguments to this function is a
boolean flag indicating whether the current job is a real print job or print
preview. The apparent intent is that this information will be stored in the
device context spec somehow.

However, the GTK version of ::CreateDeviceContextSpec() doesn't do anything with
this flag; see
<http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsDeviceContextSpecFactoryG.cpp#79>.
The Xlib version is probably similar. As a result, the printing subsystem has no
way to tell that it's being used for print preview, and just initializes using
the settings from the last print job. The PS module creates its output files and
writes the postscript prolog during initialization, so if the last real print
job was to a file, mozilla will redo those steps.

I can fix this, but it's blocked by the patch for bug 168614, which reworks
temporary files in the PS printing subsystem.

Comment 6

[Kenneth Herron]

Attachment: Add a print preview flag to the device context spec

This adds a boolean flag for print preview jobs to nsDeviceContextSpec{G|Xlib}.
In the PS module this flag is used to initialize a do-nothing print job object
for these jobs, instead of a print-to-file or print-to-pipe object.

The relationship between the print preview flag and the print-to-file/printer
flag is a bit awkward; one could argue that a single setting for {preview,
file, printer} would be better. I considered doing that here, but that would
require changes in xprint which I know almost nothing about.

As an aside, these device context spec classes look like good candidates for
deCOMtamination. I followed the existing style for the |GetIsPrintPreview()|
function, but a function returning a boolean would definitely be better style.
We already have bug 130857 about merging the GTK and Xlib versions into a
single class, but I gather it's blocked by some dispute about what directory
the new file should be stored in.

Comment 7

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

I don't think we need to be consistently COMtaminated everywhere, but I'll go
with  the way you've done it... But, where is nsPrintJobPreviewPS?

Comment 8

[Christopher Blizzard (:blizzard)]

Comment on attachment 149593 [details] [diff] [review]
Add a print preview flag to the device context spec

some tabs stuck in there where they probably shouldn't be, but other than that
appears ok.

Comment 9

[Kenneth Herron]

(In reply to comment #7)
> I don't think we need to be consistently COMtaminated everywhere, but I'll go
> with  the way you've done it... But, where is nsPrintJobPreviewPS?

roc, nsPrintJobPreviewPS is in gfx/src/ps/nsPrintJobPS.cpp. It was part of the
patch that introduced the print job classes.

Comment 10

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

Comment on attachment 149593 [details] [diff] [review]
Add a print preview flag to the device context spec

Okay, this looks good

Comment 11

[Kenneth Herron]

Checked in and cleared tinderbox. Resolving fixed.

Checking in gtk/nsDeviceContextSpecFactoryG.cpp;
/cvsroot/mozilla/gfx/src/gtk/nsDeviceContextSpecFactoryG.cpp,v  <-- 
nsDeviceContextSpecFactoryG.cpp
new revision: 1.17; previous revision: 1.16
done
Checking in gtk/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/gfx/src/gtk/nsDeviceContextSpecG.cpp,v  <-- 
nsDeviceContextSpecG.cpp
new revision: 1.63; previous revision: 1.62
done
Checking in gtk/nsDeviceContextSpecG.h;
/cvsroot/mozilla/gfx/src/gtk/nsDeviceContextSpecG.h,v  <--  nsDeviceContextSpecG.h
new revision: 1.26; previous revision: 1.25
done
Checking in ps/nsIDeviceContextSpecPS.h;
/cvsroot/mozilla/gfx/src/ps/nsIDeviceContextSpecPS.h,v  <-- 
nsIDeviceContextSpecPS.h
new revision: 1.13; previous revision: 1.12
done
Checking in ps/nsPrintJobFactoryPS.cpp;
/cvsroot/mozilla/gfx/src/ps/nsPrintJobFactoryPS.cpp,v  <--  nsPrintJobFactoryPS.cpp
new revision: 1.3; previous revision: 1.2
done
Checking in xlib/nsDeviceContextSpecFactoryX.cpp;
/cvsroot/mozilla/gfx/src/xlib/nsDeviceContextSpecFactoryX.cpp,v  <-- 
nsDeviceContextSpecFactoryX.cpp
new revision: 1.15; previous revision: 1.14
done
Checking in xlib/nsDeviceContextSpecXlib.cpp;
/cvsroot/mozilla/gfx/src/xlib/nsDeviceContextSpecXlib.cpp,v  <-- 
nsDeviceContextSpecXlib.cpp
new revision: 1.45; previous revision: 1.44
done
Checking in xlib/nsDeviceContextSpecXlib.h;
/cvsroot/mozilla/gfx/src/xlib/nsDeviceContextSpecXlib.h,v  <-- 
nsDeviceContextSpecXlib.h
new revision: 1.21; previous revision: 1.20
done

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Kenneth Herron]

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

Comment 14

[Jesse Ruderman]

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