We've just landed a short-term fix for bug 1779202 which turns off the CGLayer-backed version of cairo_quartz_surface (and puts it behind a pref). This means bug 1772225 will now be reproducible by default again.

I'm filing this bug on fixing/understanding the underlying issue that we're hitting with that backend (the scaling problem discussed in bug 1779202), so that we can reenable the CGLayer-backed version of cairo_quartz_surface.

STR (identical to bug 1779202 but now requiring a pref flip):

1. On macOS, set about:config pref gfx.cairo_quartz_cg_layer.enabled to true
2. View attachment 9288859 [details] (or one of the other PDF testcases from bug 1779202)
3. Cmd+P to print, and then click through to the system dialog
4. Click the "PDF" dropdown (at bottom left) and then "Open in Preview"

ACTUAL RESULTS:
The resulting shipping label is scaled up and clipped at the edges.

EXPECTED RESULTS:
Shipping label should be shown at the same scale (with respect to the PDF sheet-of-paper) as was shown in Print Preview, and shouldn't be clipped at the edges.

(A different but also-relevant set of STR/actual-results are in bug 1772225 comment 0, with the pref gfx.cairo_quartz_cg_layer.enabled in its default false state. That issue is what's motivating us to want to flip this pref to true, though we can't do that right now due to the scaling/clipping ACTUAL RESULTS described in comment 0 here.)

(I suspect jfkthame is the most-obvious person to take action here. Ticking ni=him to be sure this is on his radar.)

Underlying the problem we're having here is an incompatibility between how Apple's PDF-rendering software behaves, compared to all other PDF renderers I've tried.

Attached is a simple Core Graphics-based tool, to demonstrate the issue after eliminating all other layers (Skia, Moz2d, cairo, pdf.js, webrender, etc) that might come into play within Firefox.

When this tool is run, it creates an output file out.pdf that contains a 5-page PDF, generated entirely via CGPDFContext.

Viewing this PDF in Apple viewers such as Preview.app, or the Finder's QuickLook, or by opening the file in Safari, we see that pages 1, 4 and 5 all render the same; as do pages 2 and 3.

But viewing that same PDF in non-Apple viewers (including Adobe Reader as well as third-party software), each of the 5 pages renders differently. This demonstrates that Apple's handling of transforms, patterns and layers is incompatible with other PDF-rendering software in certain cases; and Core Graphics is generating PDF output that hits this incompatibility.

Compare rendering in Apple (e.g. Safari, Preview) vs non-Apple (e.g. Chrome, Firefox, Adobe) renderers; for the most obvious difference, check page 5.

Observe that only pages 1 and 2 out of the 5 pages in the file render the same in Apple and non-Apple viewers.

I've submitted "feedback" to Apple with this example via https://feedbackassistant.apple.com/feedback/11499608. (But if we have contacts in the Core Graphics and/or PDFKit groups, it might be better to reach out directly.)

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

(But if we have contacts in the Core Graphics and/or PDFKit groups, it might be better to reach out directly.)

Maybe karlcow or heycam can find someone that we could forward this along to?

(karlcow / heycam, see comment 3 -- we're hitting what seems to be an Apple CoreGraphics/PDFKit rendering bug and we're hoping to find an appropriate place/person to report it to.)

I've posted an additional sample file at https://jfkthame.github.io/test/pass-or-fail.pdf, for easy testing. This file displays a trivial page with PASS in green in all non-Apple viewers I have tried, but in Safari, or if downloaded and opened with Preview.app, it shows FAIL in red instead.

Thanks a lot Jonathan!
Super helpful.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jwatt, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Jonathan, can you share the code for producing https://jfkthame.github.io/test/pass-or-fail.pdf?

Code to generate the pass-or-fail.pdf example.

The attached patch seems to fix the behavior with all the examples I've tried, and I haven't noticed any ill effects yet. But if we take this, it'd be good to ask QA to specifically do some macOS print testing to verify it's OK.

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

We also had some reports on Mozilla Connect, we can ask the users if they are still able to reproduce.

I've tested using 108.0b4 on macOS 11.6 that the scenario from comment 0 is not reproducible anymore. We also ran a bunch of PDF related tests (some general tests and some specific tests such as PDF improvements, PDF viewer etc) while validating both 108.0b5 and 108.0b6 builds across platforms (macOS 11.6, Windows 10 and Ubuntu 22.04) and no new issues were found.

Based on the above I'll go ahead and close this issue as verified fixed.