82573 - Postscript margins are being applied 2 times

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[dcone (gone)]

Margins for printing are being applied in the reflow,and also in the Postscript 
output.

Comment 1

[dcone (gone)]

Attachment: patch that takes out the marings in the postscript.

Comment 2

[Marc Attinasi]

I think you have a typo here:

 mPrintSetup->top = (int) 0);  

(extra right-paren?)

sr=attinasi otherwise.

Comment 3

[dcone (gone)]

Attachment: fixed patch

Comment 4

[dcone (gone)]

basically.. I have the file on linux.. copied manually to windows for the patch 
file.. so I made a typo.  This patch does fix the bug.

Comment 5

[Kevin McCluskey (gone)]

r=[e-mail]

Comment 6

[MichaelWright9]

I applied this patch to my MOZILLA_0_9_BRANCH build. The left and top margins
look ok. The right and bottom margins are worse after the patch. I also
recommend that the header and footer follow the set margins. With this patch the
header/footer are pushed to close to the left edge of the page. I was using
margins setting (top/bottom = 0.50, left/right = 0.25)

Comment 7

[Roland Mainz]

Can anyone please point me to the source where reflow appiles the margins ?
Thanks !

Comment 8

[dcone (gone)]

the margins are applied to the reflow size.. and passed to reflow.. this is in 
nsDocumentViewer.cpp

Comment 9

[dcone (gone)]

I looked at this using GhostView.. and measured the document size.. and margins.
What I found.. was for the mozilla page.  the left margin looks great.. the 
right looks to wide.. but the width of the document ended up to be ~7.5 inches.. 
which is what its supposed to be (for margins of .5 all the way around).  I cant 
currently print on my linux box, but using ghostscript it looks good if I 
measure the sizes. I have looked at all the code.. and its spitting out the 
correct sizes for layout.  

I figure 8.5 inches without margins.  
8.5 - (.5+.5) = 7.5 inches wide.  What are you seeing Michael.

Comment 10

[MichaelWright9]

Don, here are my results using MOZILLA_090 with the above patch applied built 
on a Linux box.
Web page: www.cnn.com
Selected margins: 0.5 inches all the way around.
Printing to: Postscript file
Viewed using: GSview(windows) and Ghostview (Linux)

Results:
Top margin: 0.5 inches
Left margin: 0.5 inches
Right margin: 1.5 inches
Bottom margin: 1.5 inches

Width of the document (main body) ended up to be ~6.5 inches.

The top and left margins look good.

Comment 11

[dcone (gone)]

How did you measure the width of the document, I used a ruler.  Also.. does 
ghost view represent the page (right side) accuratly.  I am at a loss, because 
looking at the code.. its doing exactly what it should be, and my results using 
ghostview are correct.  The right margin looks big.. but the body and left 
margin are correct so I assumed Ghostview just did not represent the page 
correctly.  Can you print this out and see what your results are.

Comment 12

[MichaelWright9]

I measured them using the pointer position data that is displayed by GSView. I 
printed the Postscript file on 2 different printers, HP DeskJet 932C and HP 
LaserJet 8000. The results are the same. I used a ruler to measure the margins 
and width of the body. I still get the same results:
Top margin: 0.5 inches
Left margin: 0.5 inches
Right margin: 1.5 inches
Bottom margin: 1.5 inches

Width of the document (main body) ended up to be ~6.5 inches.

Have you tried this on your Linux build. It may be another one of those Linux 
quirks, like in bug#82624.

Comment 13

[dcone (gone)]

I did all my testing on linux, since the PostScript for Windows is automatically 
generated.. and would not be effected by these changes.

Comment 14

[Roland Mainz]

Michael Wright:
Could you grab http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36446
and check whether you see the same problem there, please ?
The output is from Xprint module (+Xprt PS DDX) - which should (in theory :-)
not suffer from this issue when the bug sits in native PostScript module. If the
bug is in this output, too - then the bug sits in the code shared between all
print systems (Win32/PostScript/Xprint)...

Comment 15

[MichaelWright9]

Roland, I had problems viewing this Postscript file using GSView (Win98) (got 
Document Structuring Conventions (DSC) errors about %%BoundingBox) I was able to 
view from Ghostview on Linux. The document looked ok. What were your margins?

Comment 16

[Roland Mainz]

I used the default setting for margins (0.5/0.5/0.5/0.5 AFAIK).
If the margins are correct in that output - then the issue may be in the native
PostScript module...

----

> I had problems viewing this Postscript file using GSView (Win98) (got 
> Document Structuring Conventions (DSC) errors about %%BoundingBox)

Could you please email me details about that ? This may be a bug in the PS DDX
(driver) of Xprt (or GSView is buggy... :-) ...

Comment 17

[dcone (gone)]

Attachment: New patch to fix the margins

Comment 18

[dcone (gone)]

OK.. new patch to keep the margins in line.  The bottom line here was the 
margins are being applied to the page size in the nsSimplePageSequencer.
They were also added in the nsPostScriptObj object and added into the page size 
in the nsDeviceContextPS::GetDeviceSurfaceDimensions() call.

This patch takes the margin calculation out of the last 2 calls and only the 
nsSimplePageSequencer will use them for layin out the image.  Also in the patch 
is some code with defines so that the PS code can be compiled and debugged on 
windows, but very few lines are for that.

Comment 19

[Marc Attinasi]

Looks OK to me - sr=attinasi

Comment 20

[Peter Lubczynski]

If the code is only for testing, shouldn't it be in #ifdef DEBUG's? otherwise,
r=peterl

Comment 21

[dcone (gone)]

checked in.

Comment 22

[sujay]

Michael/Roland, can you please see if this is fixed with latest build?

and mark this bug VERIFIED-FIXED if it is....

thanks.

Comment 23

[MichaelWright9]

I did a few test on this fix. Here are the results:
- Tested on nightly build 7/16 - Linux OS.

Test cases used URL: http://www.mozilla.org/projects/. Also only tested using 
Letter size paper.

Test case 1: Print above URL with margins set to 0.5"
Results: Margins are correct for main body.

Test case 2: Print above URL with margins set to 0.25"
Results: Left and top margins are correct for main body. Right and bottom 
margins are not correct. They measured ~0.75" each.

Test case 3: Print above URL with margins set to 0.75"
Results: Left and top margins are correct for main body. Right and bottom 
margins are not correct. They measured ~0.25" each.

**NOTE: in all 3 test cases the header and footer are not printed correctly 
anymore. The margins for the header and footer look to be 0.0", which most 
printers cannot print. May need to open another bug of this.

It does not look to be fixed unless you are using 0.5" margins.

Comment 24

[sujay]

REOPENING based on Michael's comments.

Comment 25

[dcone (gone)]

Attachment: Fix to make sure margins are set in time

Comment 26

[Peter Lubczynski]

looks fine, r=peterl on new patch

Comment 27

[Marc Attinasi]

sr=attinasi

Comment 28

[MichaelWright9]

I did a quick test with this latest patch and the margins look correct.

Comment 29

[Boris Zbarsky [:bzbarsky]]

do they look correct for the header as well?

If so, is bug 91321 a duplicate of this one?

Comment 30

[MichaelWright9]

The margins are incorrect for the header and footer. That is why I opened bug 
91321.

Comment 31

[dcone (gone)]

Margins are fixed.

Comment 32

[sujay]

Michael, if you can verify the fix....please mark verified-fixed or REOPEN.

thanks.

Comment 33

[MichaelWright9]

Tested on nightly build 7/19 - Linux OS.

Test cases used URL: http://www.mozilla.org/projects/
Tested Letter, Legal, and A4 paper size

Test case 1: Print above URL with margins set to 0.5"
Results: Margins are correct for main body.

Test case 2: Print above URL with margins set to 0.25"
Results: Margins are correct for main body.

Test case 3: Print above URL with margins set to 0.75"
Results: Margins are correct for main body.

verified-fixed (I do not have permissions to change status to verified)

Comment 34

[sujay]

roland/michael please verify and mark verified when you get chance

Comment 35

[sujay]

marking verified per Michael's comments...thanks!