Open Bug 1693989 Opened 3 years ago Updated 5 months ago

PDF content gets clipped when printing, if it's too close to page edge (with no way to shrink to fit printable area)

Categories

(Toolkit :: Printing, defect, P3)

defect

Tracking

()

Tracking Status
firefox87 --- affected

People

(Reporter: dholbert, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [print2020])

Attachments

(3 files)

STR:

  1. View a PDF that has content extremely close to the edges of the page, e.g. the attached PDF.
  2. Ctrl+P (or Cmd+P) to print.
  3. Choose a real printer as the print-target, with US-Letter sized paper, and proceed with the print.

ACTUAL RESULTS:
The edges of the content are clipped in the printout; moreover, there's no way to avoid this.

EXPECTED RESULTS:
Firefox should have shrunk the content to fit the printable area (or should've exposed an option to allow me to ask for that).

For comparison, Edge and Chromium both offer me "Scale|Fit to Printable Area" as a (non-default) option here, and that seems to give me EXPECTED RESULTS.

Note: we do allow the user to scale to a particular percent value, e.g. I can do "Scale:90%" -- but that doesn't help here, because we still align the scaled-down content to the extreme top left corner of the physical page, which means we still clip content up there.

I ran into this today "in the wild" when trying to print my proof-of-car-insurance documents. My insurance company gives me that as a PDF with a pretty small margin between the top left corner & the content, and there's no way to get Firefox to print that PDF without clipping content.

Here's a photo showing the output produced by the STR right now.

As you can see, content is clipped on the top and left edges, even if I try to work around it by setting a smaller scale for the printout.

(I don't think this is a toolkit::printing bug… Maybe it's a core::printing:output/Firefox::pdf viewer interaction? Tagging BDahl to see if it's something on the PDF end.)

This bug also bit me with a second PDF that I was trying to print "in the wild" today, with a slightly different sort of PDF -- a small shipping label, which had very small margins (but which nonetheless you'd expect would print just fine since it's smaller than the paper that I'm printing it onto). But in Firefox, we snap it to the extreme upper-left corner, which means content gets clipped and there's no way to work around that.

Attachment #9204393 - Attachment description: photo of my attempts to print this page in Firefox (left is default "Fit to page width"; right is 90% scale) → photo of my two attempts to print Testcase 1 in Firefox (left page is default "Fit to page width"; right is 90% scale)

(In reply to Blake Winton (:bwinton) (:☕️) from comment #2)

(I don't think this is a toolkit::printing bug… Maybe it's a core::printing:output/Firefox::pdf viewer interaction? Tagging BDahl to see if it's something on the PDF end.)

It's a whole-printing-pipeline bug - we need to expose some "scale" UI for this (probably named "Fit to page area" or similar), and then honor that in the platform.

In particular, the following things are both true, I think:
(1) We need to allow users to opt into this fit-to-printable-area behavior, so that they can print the attached PDFs without dataloss.

(2) We also need to allow users to get the currently-shipping behavior (and perhaps the current behavior would need to remain the default). Typically, PDFs do include some blank area at the edges, so they don't need any adjustment; and they might have precisely sized content that would be subtly broken if we shifted/scaled it to fit the printable area (e.g. a schematic that expects to be printed exactly onto a US Letter sized page in order for its scale to be correct).

I'm not sure the fit-to-printable-area behavior (the behavior that I'm requesting in this bug) maps cleanly onto our existing print dialog options, which is why I think we might need a new option for this.

Whiteboard: [print2020] → [print2020_v87]

Update: the PDF.js update in bug 1699313 helped us out here, significantly.

As of that bug's patch: if the printed PDF content is smaller than the physical sheet, it seems to get centered on the sheet, which is the behavior I'd expect.
That means:

  • testcase 2 now gives EXPECTED RESULTS. hooray!
  • testcase 1 still gives ACTUAL RESULTS (edges are still clipped, if your printer has any unwritable area) -- but, users can now work around this by using a custom scale in the print dialog. E.g. if you set scale to 90%, then you get a scaled-down-and-centered result, without any clipping.
Depends on: 1699313

I think bug 1698414 will fix the opposite issue, which is printing a very big page in a smaller target paper.

Whiteboard: [print2020_v87] → [print2020]
Severity: -- → S3
Priority: -- → P3

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

Update: the PDF.js update in bug 1699313 helped us out here, significantly.

Another update: this^ improvement was unfortunately short-lived.

There was another PDF.js update a few weeks later in bug 1702796 which changed/broke how PDFs scale when printing. (That behavior-change is tracked in bug 1711659 and bug 1734794.) And it turns out that behavior-change seems to have regressed both of the improvements that I mentioned in comment 8.

So, neither of the attached testcases prints nicely now, unless you manually specify unnaturally-small scale factors (~60% for testcase 1, and ~83% for testcase 2 -- despite the fact that testcase 2 is a 5.8in x 8in PDF which should already be smaller than a US-letter sheet of paper.

Hopefully once we fix bug 1711659, we'll be back to the state that I described in comment 8, which gives would give users a discoverable workaround for the time being. (Technically they have a workaround via e.g. setting 60% scale-factor right now, but that's not super discoverable since scale appears to have no effect for most scale factors closer to 100% [for PDFs] as discussed in bug 1711659.)

Depends on: 1711659
See Also: → 1669910
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: