1865203 - Google Docs print-preview doesn't seem to be matching the specified page size (A4 specified in google docs settings, but we use US Letter)

Status: RESOLVED DUPLICATE of bug 1865155

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Be using a Google account that's opted in to the "native" print flow (which requires manual action from some Google folks for now), or using UA spoofing to pretend you're Chrome.
2. Load this Google Doc (which has a single A4-sized page):
   https://docs.google.com/document/d/19yI4aEoKF7McVWCCQFm2nmuZHgY-WYbJAFC-4WUUAHU/edit?usp=sharing
3. Print Preview. Try the "Save as PDF" backend, as well as a physical printer where you explicitly choose an A4-sized print target.

ACTUAL RESULTS:

• Both backends clip the page at the bottom, and then create a second blank page (with awkward blank space at the bottom of the first page, when I'm explicitly selecting an A4-sized output sheet with my physical printer)
• More to the point: if you actually proceed with the print with the Save-to-PDF backend and look at the details of the generated PDF (per notes below), you can see that it's US Letter sized (which is why we're clipping, since the A4-sized content is taller than US Letter).

EXPECTED RESULTS:
No such clipping; we should be using an A4-sized page.

Notes:

• In the Save-as-PDF print backend, it looks like we're generating a US Letter sized page (as you can see if you click through and actually save it, and then view the PDF and look at its details).
• Probably that's what's happening with my actual physical printer selected as the print-target, too (when I manually choose A4 as the output paper size) -- we're probably generating an A4-sized canvas, putting it on a US-Letter-sized page, and then visualizing that page scaled to fit onto an A4 sheet of paper.
• So the issue seems to be that we're not picking up that Google Docs wants an A4-sized page here. (I haven't yet checked to see if we're getting a proper @page rule etc.)

Comment 1

[Daniel Holbert [:dholbert]]

This might be the underlying issue behind the apparent sizing/positioning issue in bug 1865155. My testcase here is a modified copy of the testcase from that bug.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: print result from Firefox Nightly

Here are the ACTUAL RESULTS from the Firefox Nightly save-to-PDF print target.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: print result from Chrome

Comment 4

[Daniel Holbert [:dholbert]]

(If you load those^ two PDFs in Firefox (PDF.js) and check Document properties in the use the >> menu, you can see that the Firefox-generated PDF is 8.5 × 11 in (Letter, portrait) while the Chrome-generated PDF is 8.28 × 11.71 in (portrait) which is roughly A4-sized.)

Comment 5

[Daniel Holbert [:dholbert]]

(It's possible that this is a Google Docs bug -- we should see if they're sending us the right page size here.)

If I toggle print media emulation in Firefox or Chrome, and then do File|Save and inspect the CSS, I'm just seeing two @page rules which seem to ask for US-Letter-sized pages (not A4):

@page {
 size:8.5in 11in;
 margin:0;
 visibility:hidden
}
@page landscape {
 page-orientation:rotate-right
}

So I'm not sure offhand how/where they're encoding the page size here, and how Chrome would be picking up on that when they generate their PDF. Maybe there's another @page rule that gets dynamically inserted at some point?

Comment 6

[Daniel Holbert [:dholbert]]

(In other words, the open question right now isn't "why is this broken in Firefox" but rather "how does this work at all in Chrome")

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(In other words, the open question right now isn't "why is this broken in Firefox" but rather "how does this work at all in Chrome")

I think we answered this in bug 1867106: Google Docs is modifying the @page rule dynamically, and doing so using a technique that works in Chrome but is non-standard.

This will hopefully be fixed soon on the Google Docs side, per bug 1867106 comment 4.

Comment 8

[Jonathan Watt [:jwatt]]

Possibly going to close bug 1867106 as invalid. Google is going to update Google Docs to use setProperty anyway.

Comment 9

[Daniel Holbert [:dholbert]]

We can remove this as a (closed) blocker from bug 1521655 since its dupe-target bug 1865155 is also marked as a blocker.