Note

• This issue was submitted as per the request from comment 9 from ticket 1252243
• This issue needs an actual printer in order to be reproduced and properly verified.

Found in

• 104.0a1 (20220711215641)

Affected versions

• 103.0b7 (20220710185935)

Affected platforms

• macOS 11.6.6
• macOS 12

Steps to reproduce

1. Access the following document
2. Open it with Print Preview. (set a custom range and print only the 1st page)
3. Print it to paper.

Expected result

• The logo with the three trees at the top left is properly printed.

Actual result

• The logo with the three trees at the top left of the page is mishandled (printed at the wrong scale) such that only the top-left part of it shows, the rest is clipped away.

Regression range

• As per specified in comment 4 from ticket 1252243, the pushlog_url indicates that the culprit would be 1772225.

Additional notes

• This issue can also be reproduce with the 1st page of the following document .
• List of printers used to reproduce this issue:

• Phaser 3020
• HP OfficeJet 6950
• Canon TS3451

Set release status flags based on info from the regressing bug 1772225

:jfkthame, since you are the author of the regressor, bug 1772225, could you take a look?
For more information, please visit auto_nag documentation.

I can reproduce this with "Save to Pdf" on macOS

This is a regression, but the bug was there before (bug 1252243) and was fixed by one of the patches in bug 739096, which we partially reverted in bug 1772225.

Yeah, it looks like the cglayer-backed surface implementation must be mishandling scaling in certain cases, and when we brought that code back from oblivion to fix the rasterized output, the problem came with it.

(It'd be nice to have a really minimal example of a PDF that exhibits this problem, if someone wants to try creating one.)

Set release status flags based on info from the regressing bug 1772225

Today on SUMO, two Mac users reported that when they print PDFs, the images are much larger than they should be and are clipped and therefore portions of them are lost.

• https://support.mozilla.org/questions/1384467
• https://support.mozilla.org/questions/1384481

Are there any workarounds or mitigations for this that Firefox 103 users could employ?

Can anyone relay advice to SUMO on what proportion of PDFs are likely to suffer from this problem? That could help in determining whether to suggest to Mac users that they change their default PDF handling action from "Open in Firefox" to "Use Preview" or "Use Acrobat" if they need to print frequently.

On a MAC even setting FF to open PDF with Acrobat as a workaround still appears to open with the FF built in reader and does not print correctly.

(In reply to rfm from comment #8)

On a MAC even setting FF to open PDF with Acrobat as a workaround still appears to open with the FF built in reader and does not print correctly.

Setting the action on the Settings/Preferences page should cover most PDFs: https://support.mozilla.org/kb/view-pdf-files-firefox-or-choose-another-viewer

If there are PDFs that download and open in Firefox after saving (the address bar shows a file:/// address), use the Downloads list (toolbar button or Command+J) to launch the PDF in Acrobat: right-click (Ctrl+click) the item and choose Open in Acrobat from the context menu.

For further assistance with working around this bug, you can post on Mozilla Support: https://support.mozilla.org/questions/new/desktop/form

This bug causes certain PDFs to be clipped when printed from Firefox on macOS -- e.g. the 4x6 "pirateship" shipping label in bug 1783528, attachment 9288859 [details] , which gets clipped at the edges even when printing to US-letter-sized paper. This clipping issue happens with our Save-to-PDF backend, as well as the system print dialog "PDF|Open-in-Preview" menu.

For reference/archival, here's the PDF that's linked in the additional-notes at the end of comment 0.

Here's what I get if I do save-to-PDF with the original testcase ("Access the following document" from comment 0, which links to attachment 8724920 [details]).

Just as noted in bug 1783528 comment 13, this Firefox-generated PDF seems to render just fine in all PDF viewers (e.g. Firefox, Chrome, evince), except for the Preview app on macOS where it shows the tree-logo being clipped per the photo in comment 0.

So there seems to be some special incompatibility with Preview (and presumably downstream parts of the macOS printing machinery) with the PDF content that we're generating.

If I do another iteration (view the save-to-pdf generated PDF in Firefox, and print with our Save-to-PDF print target), then I get output that's differently (and more-thoroughly) broken in the macOS Preview app.

Here's that PDF. The macOS Preview app renders just the bottom-left quadrant of both pages here, scaled up to the full page size, it seems. (The other 3 quadrants of each page are pushed off the page & hence unreadable.)

To help visualize for those who don't have a mac handy, here's a screenshot of macOS Preview's rendering of 3 PDF files:
left: original doc (attachment 8724920 [details])
middle: Firefox's save-to-PDF output of that original document (attachment 9289104 [details])
right: Firefox's save-to-PDF output of that^ save-to-PDF output (attachment 9289124 [details])

These PDF files all look the same if I view them in Firefox or Chrome or Evince, but they look very different in Preview (and similarly look different when actually printed on mac, presumably due to shared system PDF-rendering mechanisms there).

jfkthame, do you have cycles to look into this?

It looks like we'll be shipping this as a regression in Firefox 104, though we do have a few days to fix it if we can come up with a safe fix. (Or if we can't fix it for 104, it'd be nice to have a fix ready for 105, given that this is a pretty-visible regression.)

(This was classified as S3, but it feels more S2 level to me. --> increasing severity.)

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

It looks like we'll be shipping this as a regression in Firefox 104

(Oh, I guess we shipped it in 103 already. :) Still, would be nice to fix soon.)

(In reply to Jonathan Kew [:jfkthame] from comment #5)

(It'd be nice to have a really minimal example of a PDF that exhibits this problem, if someone wants to try creating one.)

bug 1783528 has a couple fairly-minimal testcases from an affected 4x6 shipping label:

• the reporter's attachment 9288859 [details] (24.40 KB)
• my hand-edited-to-reduce-it version, attachment 9290237 [details] (19.81 KB)

The vast majority of the file-size is from in a single binary blob that encodes an image, I think.

(I tried reducing the testcase further, but I kept inadvertently producing a version that worked fine in one PDF viewer but was blank/corrupt in another one [presumably due to more/less graceful handling of errors & missing data]. So I'm stopping here for the time being.)

Yes, the problem here is associated with images embedded in the PDF (as XObject resources, in PDF terms) that are somehow being mis-scaled. In the shipping label case, there is a single image that is the entire label as a grayscale bitmapped image.

The shipping label bitmap is 1200 pixels wide by 1800 pixels high. Rendered at 300dpi, this would be exactly 4 x 6 inches; but what I suspect is happening is that it is instead being rendered at 72dpi, and therefore appears (just over) 4x too large.

What's not clear to me at the moment is where the confusion arises. It looks like the image ends up getting rendered in the output by treating it as a pattern source, and I guess the resolution/scaling to be applied to the image-used-as-pattern is potentially lost somewhere.

The fact that the result of save-to-pdf renders correctly in Acrobat Reader (and also in Foxit PDF reader, MS Edge, etc) but wrong in Preview.app suggests to me that what we're actually seeing here is a bug in CoreGraphics PDF handling, but I'm not sure how easily we can prove that; and even if we can, it'll take time for a fix to appear. So we should try to figure out how to avoid the scenario that it mishandles.

I may be misunderstanding what is meant by "wrong in Preview.app" but fwiw the 4x6 labels DO display and print correctly for me from MacOS Preview:

1. Open attachment 9290237 [details] in Firefox
2. Click print icon in upper right and proceed to print -- BAD print result
3. Click download icon in upper right to download
4. Go to Finder and open file in Preview
5. File > Print -- GOOD print result

MacOS 12.4
Preview 11.0 1033.4
Firefox 103.0.2 (64-bit)

robgwin: RE "wrong in Preview.app", see comment 13 here and also bug 1783528 comment 13. (The original PDF looks fine in Preview.app, but if you use Firefox to print-it-to-PDF, then the resulting PDF looks broken in Preview.app (in the same way that the printout looks broken) but renders just fine in other PDF viewers.)

dholbert: aha, thanks.

Here's something potentially interesting: I just found I can reproduce this problem on MacOS (12.4) without any Firefox involvement:

1. Use Safari or whatever to download Rollo's sample label: https://www.rollo.com/sample/
2. Open the file in preview and print. All good.
3. Now select the file in Finder and just hit spacebar to open it in quickview. Notice it looks bigger than it did in preview. Cmd-p to print and it prints big!

This is being reported very frequently.

Should we try to find a workaround here and in the meantime contact Apple to let them know of this bug?

Yes, we should definitely try to work around this somehow, though I haven't yet been able to identify exactly what a workaround would involve.

A bug report to Apple would be great, but would be much more useful and actionable if we could reduce it to a standalone CoreGraphics example that demonstrates the issue.

Printing of USPS labels is also affected, PDF available at https://github.com/mozilla/pdf.js/files/9479991/ebay-label.pdf.

Hi Frank, is there a chance we can get some eyes on this or some clarity on a possibility of a patch? Or is there a way to get a bug report submitted to Apple to investigate?

(In reply to Taddes Korris [:taddes] from comment #31)

Hi Frank, is there a chance we can get some eyes on this or some clarity on a possibility of a patch? Or is there a way to get a bug report submitted to Apple to investigate?

Needinfo for the question above ^.

We are getting more reports on Mozilla Connect too (last one about Etsy labels being broken too).

Yeah, this bug needs an owner - even if it's just working on getting a reduced testcase to send to Apple. My worry is that even if they do fix the underlying CoreGraphics bug, it's extremely unlikely they'll do so for anything older than macOS 12 and we'll still have a sizeable population of users affected. If we can't find a workaround on the Firefox side, I wonder if we should back out the regressing change instead as this issue seems worse than the original bug we were trying to fix.

JKew and DHolbert are currently discussing short term backout options. Stay tuned.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #33)

Yeah, this bug needs an owner - even if it's just working on getting a reduced testcase to send to Apple.

Just FTR, I spent some time trying to work on this, without any useful results so far.... will try to poke further.

My worry is that even if they do fix the underlying CoreGraphics bug, it's extremely unlikely they'll do so for anything older than macOS 12 and we'll still have a sizeable population of users affected.

Agreed; we need to work around this somehow.

This avoids the apparent Core Graphics bug whereby the PDF output it generates will mis-render
when subsequently processed again by Core Graphics (although it renders OK in Adobe products).
Unfortunately, this will regress bug 1772225, so that pdf.js documents will be rasterized when
printed or in Save to PDF output on macOS.

(Setting the pref gfx.cairo_quartz_cg_layer.enabled to true will restore "good" (vector-based)
output, but embedded XObject bitmap images may be mis-scaled.)

https://hg.mozilla.org/mozilla-central/rev/b02c818f2a01

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox105 to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9293324 [details]
Bug 1779202 - Disable use of CGLayer-backed cairo quartz surfaces to work around scaling bug affecting XObject images in pdf.js output. r=dholbert

Beta/Release Uplift Approval Request

• User impact if declined: Raster graphics within PDF documents may be mis-scaled when printed (or saved to a new PDF) on macOS.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: On macOS, open the example PDF files attached to this bug & dupes; print to Save-to-PDF or to a real printer, and verify that images are correctly scaled when printed, or when the saved PDF is opened in Preview.app.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch just disables the new code path that was introduced in bug 1772225 and reverts to pre-existing behavior, so there's little risk of unexpected side-effects.

Note, however, that this will regress bug 1772225, so that pdf.js documents will be rasterized when
printed or in Save to PDF output on macOS. This seems a lesser evil than the (fairly widespread) instances of badly mis-scaled graphics.

• String changes made/needed:
• Is Android affected?: No

Comment on attachment 9293324 [details]
Bug 1779202 - Disable use of CGLayer-backed cairo quartz surfaces to work around scaling bug affecting XObject images in pdf.js output. r=dholbert

Agreed that the pros outweigh the cons on this one. Approved for 105.0b9.

https://hg.mozilla.org/releases/mozilla-beta/rev/b0c654f7c680

Hello,

Confirming this issue as verified fixed on 105.0b9-build1(ID: 20220908185813) and Nightly 106.0a1.
Verified using macOS 10.15, macOS 11 and macOS 12 and Phaser 3020 , Canon TS3400.