375749 - Print & Print-Preview shifts document down and to left, cutting off headers

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: PDF of Google from branch

STR:

1. http://www.google.com
2. Print, or save to PDF
3. Examine printout/PDF

Actual: Observe no margin between page title header and left edge (and/or possibly a truncated page title, depending on title length); compare with branch

Expected: Equal left and right margins

Using fresh profiles on CmTrunk-2007-03-27-22 and CmBranch-2007-03-28-04.

Note also that in the trunk PDF, the content seems to be shifted down a bit; not sure if that's part of this bug or not.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: PDF of Google from trunk

(This was actually too large to attach to Bugzilla as generated; I ran it through Acrobat's "Reduce File Size" preset and it shaved off 40K.)

Comment 2

[philippe (part-time)]

Attachment: screenshot

The whole 'page' is shifted down, and moved slightly to the right, even with headers/footers disabled.
On the screenshot, left is pdf output from Camino branch - right is current Minefield.
Page is here: http://www.l-c-n.com/IE5tests/
(I took that one because it has good control via a print stylesheet).

Comment 3

[Stuart Parmenter]

dup of a cross-platform bug that should probably be a blocker.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I've never been able to find the bug from comment 3 :( so twiddling all the flags on this one.

Comment 6

[Stuart Parmenter]

i can't find it either, although i know it is out there.

Comment 7

[Marcia Knous [:marcia]]

Still happens with Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2. If we can't find the other bug I would suggest making this the primary bug.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to comment #3)
> dup of a cross-platform bug that should probably be a blocker.

I actually don't think this is a cross-platform bug... Here are the behaviors I see on all platforms for printing google.com to a PDF:

Windows/Linux
 * FF2:   No margin between title and left edge, or between URL and right edge
 * FF3b2: (same as FF2)

 Hence, no regression on those platforms.

Mac OSX
 * FF2:   There is a margin between title and left edge, as shown in PDF
 * FF3b2: No margin between title and left edge AND whole page is shifted down.
(as described in comment 0)

 ==>  Switching this back to a mac-only bug.  (but let me know if I'm missing something)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to comment #9)
>  * FF3b2: No margin between title and left edge AND whole page is shifted down.
> (as described in comment 0)

I see this issue in Print Preview as well.

Comment 11

[Daniel Holbert [:dholbert]]

Taking a crack at this.
 --> Assigning to me.

Comment 12

[Daniel Holbert [:dholbert]]

AFAICT, the last Mac nightly that successfully printed Google (without everything shifted down) is:
  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061121 Minefield/3.0a1

The next day's nightly build won't print at all, and after that I get either no printing or just blank pages, until I reach this nightly 4 months later:

  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070328 Minefield/3.0a4pre

(Note that this nightly is from the day this bug here was filed)

It looks like we started printing *something* again due to the checkin for bug 368933.

So, anyway, the regression that caused this bug is somewhere in there...

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to comment #12)
> AFAICT, the last Mac nightly that successfully printed Google (without
> everything shifted down) is:
>   Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
> Gecko/20061121 Minefield/3.0a1

The only checkin that I can see breaking printing for the next day's nightly is bug 323934, "Change default toolkit on Mac to cairo-cocoa"

> The next day's nightly build won't print at all, and after that I get either
> no printing or just blank pages, until I reach this nightly 4 months later:
> 
>   Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre)
> Gecko/20070328 Minefield/3.0a4pre
> 
> (Note that this nightly is from the day this bug here was filed)

Here's the (huge) list of checkins in this regression range

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-21+04%3A00%3A00&maxdate=2007-03-28+12%3A00%3A00&cvsroot=%2Fcvsroot

Comment 14

[Daniel Holbert [:dholbert]]

From playing with page margin settings...
  (via File | Page Setup, then Paper Size | Manage Custom Sizes)
... it looks like both vertical margins are getting grouped as the top margin, and both horizontal margins are getting grouped as the right margin.

i.e.:
  Observed LeftMargin     = 0
  Observed BottomMargin   = 0
  Observed TopMargin      = TopMargin + BottomMargin
  Observed RightMargin    = RightMargin + LeftMargin

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It looks like you have a handle on the actual bug, but the sordid history of [Cairo]-Cocoa printing was that it didn't exist, was enabled in bug 359124, failed a lot, stopped working again, switched to CUPS, then to the PrintManager APIs, then to something else that was finally working, at which point I started filing bugs on everything I saw.

If the goal is to find when/where it broke, just starting from bug 359124, Stuart says "we don't do print options right" (comment 1), and the "we don't honor print settings" bug seems to have been fixed by bug 367433; maybe something in one of those jumps out.  

If nothing jumps out, presumably we could narrow down the checkin candidates by looking at just mozilla/layout, mozilla/gfx, and mozilla/widget (or perhaps even only mozilla/widget, given it seems to be Mac-only)...

Comment 16

[Daniel Holbert [:dholbert]]

Thanks, Smokey! I looked through those bugs and looked through some directory-specific bonsai requests, and nothing jumped out at me...

I think I figured it out, though.  Basically, we're just *never checking or using the specified margins at all*.

  Fact #1:  We *are* getting the correct amount of imageable page area when we set up our surface, and so our surface ends up being the right dimensions.  (The size originates in nsDeviceContextSpecX::GetPageRect, which returns the page size, not including margins.)

  Fact #2:  The surface ends up positioned all the way at the lower-left corner of the page.

  Fact #3:  The lower-left corner of the page **is the origin in Quartz 2D**. (at least, I think it is, and this  document says so: http://www.macdevcenter.com/pub/a/mac/2004/11/02/quartz.html)


We could correct this using one of the following techniques:

  A) Request a larger surface (the full size of the paper, not the drawable area) and then not just make sure not to draw in its margins

  B) Keep the surface the same size, but position it on the paper in such a way that it respects the paper's margins.  
   i.e. surface's (0,0) = paper's (LeftMargin, BottomMargin)

I imagine (B) is the better solution, if it's possible. (I'm still getting acquainted with the GFX / Carbon printing code. :))

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: patch v1

This patch seems to fix the problem, implementing solution (b) above.  Haven't tested it much yet; I'll post more after I have.

This patch also replaces a call to the deprecated function PMSetJobNameCFString with the equivalent non-deprecated function, PMPrintSettingsSetJobName.
Reference:  http://tinyurl.com/3dfmf7

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: patch v2: include margin when positioning CGContext

Slightly cleaner version of previous patch.  

It just does the following:
 - Replaces call to deprecated PMSetJobNameCFString() (see comment 17)
 - Creates the function nsDeviceContextSpecX::GetPageMargins
 - Adds the margins when we set up the CGContext

This patch makes Print-To-PDF output from trunk look like that from branch.  I tested it with other pages and with a variety of margin settings, and it works on those as well AFAICT.

Comment 19

[Daniel Holbert [:dholbert]]

Thanks for the review!  Patch v2 checked in.

Checking in widget/src/cocoa/nsDeviceContextSpecX.h;
/cvsroot/mozilla/widget/src/cocoa/nsDeviceContextSpecX.h,v  <--  nsDeviceContextSpecX.h
new revision: 1.6; previous revision: 1.5
done
Checking in widget/src/cocoa/nsDeviceContextSpecX.mm;
/cvsroot/mozilla/widget/src/cocoa/nsDeviceContextSpecX.mm,v  <--  nsDeviceContextSpecX.mm
new revision: 1.11; previous revision: 1.10
done

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Verified in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre.