1815555 - Printout has incorrectly oriented sheet of PDF-paper, when using the new "use_page_rule_size_as_paper_size" feature, with a landscape-oriented @page size rule

Status: RESOLVED DUPLICATE of bug 1793220

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

(Filing this preemptively as a followup for bug 1793220.)

STR:

1. Start a Firefox build with bug 1793220's patches applied (presumably they'll be in Nightly soon).
2. Set the about:config pref print.save_as_pdf.use_page_rule_size_as_paper_size.enabled to true
3. Load the attached testcase (which has a 4x3 landscape-oriented rectangle and @page size rule).
4. Print to PDF, choosing "Pages per sheet: 2" in our print dialog
5. Open the resulting PDF.

EXPECTED RESULTS:
The PDF should show a portrait-oriented sheet of paper, with two landscape-oriented pages shown on it (stacked vertically).

ACTUAL RESULTS:
The PDF shows a landscape oriented sheet of paper, with two landscape-oriented pages shown on it, stacked vertically, with the bottom of the lower one cut off.

It looks like we're neglecting to do the special 2-or-6-pages-per-sheet "flip the orientation" step, when setting up our output page size. (We have some code that's supposed to handle this under HasOrthogonalSheetsAndPages, but we might be imposing the author page size after we've already passed that code, perhaps?)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: print-to-PDF output from testcase 1 with 2 pages-per-sheet (showing the bug)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (swapped dimensions, which avoids the issue somehow)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: print-to-PDF output for testcase 2 (works fine!)

Here's the print-to-PDF output for testcase 2, which is just fine.

Comment 4

[Daniel Holbert [:dholbert]]

Aha! I've got some simpler updated STR -- it turns out this doesn't require 2-pages-per-sheet! It just requires a document with landscape-oriented dimensions, in general. It seems that we're mistakenly assuming a portrait-oriented page, when we determine the size/orientation of the output sheet of paper.

Simpler STR:
Steps 1-2: same setup as comment 0 (i.e. use a build with bug 1793220's patches, and the pref enabled).
3. Load the attached "testcase 1" (which has a 4x3 landscape-oriented rectangle and @page size rule).
4. Print to PDF, using default settings.
5. Open the resulting PDF.

EXPECTED RESULTS:
Landscape-oriented "pdf paper".

ACTUAL RESULTS:
The PDF has portrait-oriented paper, though the content is landscape-oriented (and gets clipped as a result).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: print-to-PDF output from testcase 1 with default settings i.e. 1 page-per-sheet (showing the bug)

Comment 6

[Daniel Holbert [:dholbert]]

Notably, print-preview shows the correct/expected result in all cases here. It's only the actual PDF "printout" that ends up with the paper using the wrong orientation.

Comment 7

[Daniel Holbert [:dholbert]]

(It's possible there's a platform-specific issue here, too; I'm using Linux, and I think fchasen wasn't seeing this issue a few days ago when we discussed this issue & he was testing the same patch on macOS.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (single-page version of first testcase)

Comment 9

[Daniel Holbert [:dholbert]]

A few notes from looking in pernosco ( https://pernos.co/debug/eo2SDpsaT_RXV38gdGDAmA/index.html#f{m[BDQV,IrR/_,t[KQ,De0j_,f{e[BDQV,IrQZ_,s{af9llAmAA,bChk,uERQJHw,oERzJYg___/ ) in a build with https://phabricator.services.mozilla.com/D160303 applied.

We find ourselves at line 581 here: https://searchfox.org/mozilla-central/rev/b25ff1fab82c2d3a91531ad3735e50422407b163/widget/gtk/nsPrintSettingsGTK.cpp#581
with *aWidth being larger than *aHeight (i.e. we've already got width/height set up as a landscape-oriented size), and we have gtkOrient being GTK_PAGE_ORIENTATION_LANDSCAPE

So we flip width/height again due to gtkOrient to "get into landscape mode". But in fact that gets us a portrait-mode size, since we already had a landscape mode size.

So it looks like internally, we expect our representation of the paper-size to be stored with width <= height, such that we can flip it per gtkOrient to produce a landscape-oriented size.

One place where we could fix this is in print.js where we assign settings.paperWidth etc. -- we might want to use min/max there to enforce our width<=height paper size invariant. (There might be a more elegant earlier place to fix this too, to effectively produce the same invariant; e.g. maybe even in nsFrameLoader::PrintPreview, the first chunk in https://phabricator.services.mozilla.com/D160303 . But that's complicated by the fact that we potentially may or may not have an explicit orientation there as well.)

Comment 10

[Fred Chasen [:fchasen]]

As suggested above, this has now been addressed as part of the patch for enabling using at-page size in https://phabricator.services.mozilla.com/D160303 by always treating the size passed by the size rule as portrait and setting the orientation as needed for the original size.

This matches our handling of default paper size, for instance we only ever pass the letter size as "8 x 11" for either orientation.

Comment 11

[Daniel Holbert [:dholbert]]

Let's just dupe this to bug 1793220, since we're ending up fixing this as part of that bug (preventing this from ever being an issue, hooray!)