1908587 - [macOS] mozPrintCallback produces rasterized text (unselectable and blurr-when-zoomed), e.g. for PDF.js and in "native" Google Docs printing flow

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Daniel Holbert [:dholbert]]

STR (same as bug 1865200 basically):

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 a Google Doc with some text, e.g. this one
3. Ctrl+P
   (Hopefully this triggers a print-preview popup. If it doesn't, go back to step 1.)
4. Click through Firefox's print UI to choose the "Save to PDF" print target and go ahead and save it.
5. Load the resulting PDF in a PDF viewer, and try to select the text, and try to zoom in.

ACTUAL RESULTS:
The text is selectable (this is what differs from bug 1865200), BUT it doesn't zoom crisply. The characters are blurry.
EDIT: Actually the text is not selectable if I view the PDF in Firefox. It is selectable in Preview.app, but that might be from some fancy OCR that Preview.app is doing? not sure.

EXPECTED RESULTS:
Text that zooms crisply.

Firefox Nightly 130.0a1 on macOS gives ACTUAL RESULTS.
Chrome on the same machine gives EXPECTED RESULTS.
Firefox Nightly 130.0a1 on Linux gives EXPECTED RESULTS.
(Haven't tested Windows yet)

So this might be macOS-specific?

This might be a general issue with mozPrintCallback, though I'm not sure (haven't tested yet).

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: resulting PDF from Firefox Nightly 130.0a1 on macOS (showing the bug)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: resulting PDF from Firefox Nightly 130.0a1 on Linux (no bug)

Comment 3

[Daniel Holbert [:dholbert]]

Related historical bugs: bug 1487467, bug 1308259.

This mozPrintCallback testcase from bug 1308259 might be a useful testcase here. If I print that testcase to PDF from Nightly and then view the resulting PDF in Nightly:

• on macOS: the "Test" text ends up all rasterized/unselectable.
• on Ubuntu: the "Test" text under "data: loading print" and "api loading print" is nicely selectable.

So it seems like this is a regression of precisely bug 1308259 on macOS. (regression range TBD, but the bug itself seems to be as-described in bug 1308259.)

I can try to track down a regression range tomorrow [hence setting needinfo=me], if nobody else gets to it first. (I would guess maybe one of the cairo updates might've done it.)

Comment 4

[Jonathan Kew [:jfkthame]]

I haven't confirmed it yet, but my hunch is that the workaround in bug 1901043 may have regressed this.

Comment 5

[Jonathan Kew [:jfkthame]]

I just made a local build with bug 1901043 backed out, and I'm still getting blurry/rasterized text in a PDF from GDocs. So maybe it wasn't that after all.... further investigation needed.

Comment 6

[Jonathan Kew [:jfkthame]]

As far as I can see from running mozregression, this has been broken -- generating rasterized text when printing to PDF from GDocs on macOS -- ever since bug 1892913 (the cairo-1.18.0 update) landed. (Daniel, maybe you can double-check that?)

(Given this, I'm surprised -- and sad -- that it hasn't been noticed/reported until now.)

We probably need to revert patch 22 from the stack in that bug, which may also require fixing up some cairo-quartz API if it has changed such that the old thebes code no longer matches what cairo provides.

Comment 7

[Jonathan Kew [:jfkthame]]

Try push with an attempt to work around this, by restoring the pre-1.18.0 cairo-quartz code in its entirety:
https://treeherder.mozilla.org/jobs?repo=try&revision=12fbe88b16bb19f2b0d45e35e846cff2e47c74e3

Comment 8

[Daniel Holbert [:dholbert]]

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

As far as I can see from running mozregression, this has been broken -- generating rasterized text when printing to PDF from GDocs on macOS -- ever since bug 1892913 (the cairo-1.18.0 update) landed. (Daniel, maybe you can double-check that?)

A quick spot-check confirms that as the regressor, at least using the mozPrintCallback testcase that I linked above.
2024-05-05 is "good" (matches description for Ubuntu on comment 3)
2024-05-08 is "bad" (matches description for macOS on comment 3)
(I chose those dates because the patches landed on autoland and then central on 5/6 and 5/7, so I spot-checked the Nightlies before & after those days)

Comment 9

[Daniel Holbert [:dholbert]]

Alternate STR here, just using our PDF viewer (which uses mozPrintCallback to render text when printing a PDF):

1. View any page with text, e.g. data:text/html,This is some text
2. Print to PDF.
3. View the PDF in Firefox, and notice that the text is selectable.
4. Print the PDF to a new PDF.
5. View that new PDF in Firefox.

ACTUAL RESULTS:
The final PDF (from printing PDF to PDF) has rasterized text -- blurry and unselectable.

Comment 10

[Daniel Holbert [:dholbert]]

Confirmed the regressor with autoland builds before (good) and after (bad) bug 1892913's patch stack.
before: mozregression --repo autoland --launch 9daa351f875bf247036785e3559a9814ff5b25ad
after: mozregression --repo autoland --launch 2175f8e4c8c9ec62e4b331c21d0dc8e5855da0f8

Comment 11

[Daniel Holbert [:dholbert]]

The try run from comment 7 does seem to address the issue for me, with the comment 9 STR as well as the comment 3 mozPrintCallback testcase. The text ends up selectable and scales crisply. (Launched as mozregression --repo try --launch 12fbe88b16bb19f2b0d45e35e846cff2e47c74e3)

Comment 12

[Daniel Holbert [:dholbert]]

I confirmed that the Try run from comment 7 produces selectable vector-drawn text with an actual Google Doc, too (the comment 0 STR), as-expected.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 14

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1908587 - Revert all cairo-quartz code (quartz-surface, quartz-font, quartz-image) to the version prior to the cairo-1.18.0 update. r=#gfx-reviewers

The cairo-1.18.0 version of the cairo-quartz backend is resulting in unwanted
rasterization of the output when printing GDocs to PDF (or to a real printer,
presumably).

It's likely this would affect other canvas-based content as well.

The problem in the 1.18.0 backend probably relates to failing to use CGLayer-
backed surfaces in certain cases, but will require more extensive debugging
to fully understand and resolve.

Given that this worked better prior to the cairo-1.18.0 update (using the
old cairo-quartz backend that included a number of mozilla-specific adaptations,
including CGLayer support), the simplest/safest mitigation in the short term
seems to be reverting the entire quartz backend. Fortunately, it is sufficiently
isolated from the rest of cairo that this can be done without touching any
other cairo code outside the macOS-specific cairo-quartz-* files.

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1908587 - Backout changeset 8fe914e33e27 (bug 1892913, patch 22), so that we explicitly use a CGLayer-backed quartz surface when appropriate. r=#gfx-reviewers

Comment 16

[Daniel Holbert [:dholbert]]

I have the makings of a test for this, I think, BTW (using mozPrintCallback in a canvas in a WPT-style print test).

It passes on linux and fails on macOS right now; I'm in the midst of rebuilding with the attached patches, and should know if they make the test pass later on today.

Comment 17

[Jonathan Kew [:jfkthame]]

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

I have the makings of a test for this, I think, BTW (using mozPrintCallback in a canvas in a WPT-style print test).

It passes on linux and fails on macOS right now; I'm in the midst of rebuilding with the attached patches, and should know if they make the test pass later on today.

Thanks - we're sorely lacking automated test coverage here (obviously), so this would be awesome. I'm going to go ahead and lando the patches here, so that we can start getting Nightly testing, but adding a test to ensure we don't regress this again in the future would be hugely helpful.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/05bf7d6afa7d
Revert all cairo-quartz code (quartz-surface, quartz-font, quartz-image) to the version prior to the cairo-1.18.0 update. r=gfx-reviewers,jrmuizel
https://hg.mozilla.org/integration/autoland/rev/bd02e7030721
Backout changeset 8fe914e33e27 (bug 1892913, patch 22), so that we explicitly use a CGLayer-backed quartz surface when appropriate. r=gfx-reviewers,jrmuizel

Comment 19

[Jonathan Kew [:jfkthame]]

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

I have the makings of a test for this, I think, BTW (using mozPrintCallback in a canvas in a WPT-style print test).

Another possible approach to testing this might be to generate a PDF that contains some text, then load it back into the browser as a pdf.js-viewer page, and then check that document.fonts is non-empty (because the PDF should contain embedded fonts that pdf.js loads as webfont resources to render them).

Comment 20

[Jonathan Watt [:jwatt]]

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

I have the makings of a test for this, I think, BTW (using mozPrintCallback in a canvas in a WPT-style print test).

Does that work by scaling up the rendering or something?

Having the test(s) be WPT tests would definitely be preferable but if that doesn't work out maybe we can use our print reftests. They're supposed to support a <type> of print which should check that the same strings appear in the test and reference output.

Comment 21

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/05bf7d6afa7d
https://hg.mozilla.org/mozilla-central/rev/bd02e7030721

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #20)

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

I have the makings of a test for this, I think, BTW (using mozPrintCallback in a canvas in a WPT-style print test).

Does that work by scaling up the rendering or something?

Exactly, yeah; I'm just comparing Ahem X glyph, drawn-to-a-canvas in mozPrintCallback, vs. <div>X</div> essentially, under the influence of transform: scale(2) for example.

Interestingly: when the canvas isn't scaled, I do get a column of antialiased gray pixels at the right edge of the Ahem glyph (when drawn with mozPrintCallback). That only happens on macOS, and it happens even with the fix that landed here. But with scale(2) and scale(4), those gray pixels go away (in a build with the fix that landed here).

I agree that a "print reftest" of the flavor that checks-for-strings would be great, too, but I don't have cycles to add one of those right now.

Comment 23

[Jonathan Kew [:jfkthame]]

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

Interestingly: when the canvas isn't scaled, I do get a column of antialiased gray pixels at the right edge of the Ahem glyph (when drawn with mozPrintCallback). That only happens on macOS, and it happens even with the fix that landed here.

I wonder if using a different font size (isn't 25px supposed to be good for Ahem in tests, IIRC?) might help avoid this?

Comment 24

[Daniel Holbert [:dholbert]]

Indeed, yeah. I had tried 30px and 50px and 100px and IIRC those all resulted in a column of antialiased pixels in the test output (50px actually does on Linux too), but 60px seems to be reliably crisp, so that's that I'm using in the patches that I just posted in bug 1908969.

(I don't personally like using 25px Ahem because it's odd, which makes for off-by-one issues in some tests as discussed in bug 1808788. I think the only magic thing about 25px is that it's divisible by 5, so other similar-magnitude font-sizes that are also divisible-by-5 should be just as good.)

Comment 25

[Jonathan Kew [:jfkthame]]

As a heads-up, while I believe the patches (reversion of cairo changes) here will have resolved the rasterized-output problem, I'm concerned that this will likely have regressed other reported issues that were fixed by the cairo update, e.g. bug 1854094 and bug 1896915. So this probably isn't an entirely satisfactory way forward.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

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-firefox129 to wontfix.

For more information, please visit BugBot documentation.

Comment 27

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1908587 - Revert all cairo-quartz code (quartz-surface, quartz-font, quartz-image) to the version prior to the cairo-1.18.0 update.

The cairo-1.18.0 version of the cairo-quartz backend is resulting in unwanted
rasterization of the output when printing GDocs to PDF (or to a real printer,
presumably).

It's likely this would affect other canvas-based content as well.

The problem in the 1.18.0 backend probably relates to failing to use CGLayer-
backed surfaces in certain cases, but will require more extensive debugging
to fully understand and resolve.

Given that this worked better prior to the cairo-1.18.0 update (using the
old cairo-quartz backend that included a number of mozilla-specific adaptations,
including CGLayer support), the simplest/safest mitigation in the short term
seems to be reverting the entire quartz backend. Fortunately, it is sufficiently
isolated from the rest of cairo that this can be done without touching any
other cairo code outside the macOS-specific cairo-quartz-* files.

Original Revision: https://phabricator.services.mozilla.com/D217012

Comment 28

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1908587 - Backout changeset 8fe914e33e27 (bug 1892913, patch 22), so that we explicitly use a CGLayer-backed quartz surface when appropriate.

Original Revision: https://phabricator.services.mozilla.com/D217013

Comment 29

[Donal Meehan [:dmeehan]]

:jfkthame the uplift request is missing an uplift form. Could you add one in the Phabricator revision when you have a moment?

Comment 30

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: MacOS print/pdf output from Gsuite (and other canvas-based apps) is prematurely rasterized, resulting in poor rendering & non-selectable text
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: See STR in comment 9 and comment 3
• Risk associated with taking this patch: low-to-moderate
• Explanation of risk level: Reverting to previous version of the cairo-quartz backend, so the code is relatively well-tested, but this is expected to regress a couple of issues that were fixed by the cairo update (see comment 25)
• String changes made/needed: none
• Is Android affected?: no

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/1508ea6a1846
https://hg.mozilla.org/releases/mozilla-beta/rev/9a30ad1bb349

Comment 32

[Daniel Holbert [:dholbert]]

FWIW I just retested the STR in comment 0 here and confirmed that the rasterization issue is no longer present with Google Docs (using Nightly 130.0a1 2024-07-23 on macOS).

Comment 33

[Raluca Popovici, Desktop QA]

I reproduced this issue according to the steps from comment 3 and comment 9 using Fx 128.0esr on macOS 13.
This issue was verified as fixed using Fx 129.0b8 and Nightly 130.oa1 on macOS 13.