2036587 - Content missing when printing PDFs

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Attachment: printed PDF

Bisected with mozregression to the Cairo update, naturally.

Attempting to print a PDF of sheet music, the lyrics and notes are completely missing, reproducible on paper and printed to PDF. Some kind of layering issue? I've attached a PDF of what the printed output looks like and will find a way to share the original copywritten PDF with whomever wants to investigate.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

I should note that this was happening on Windows 11 in my case.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

The printed PDF is also almost 4MB when the original file was only a bit over 200kB.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

There's been a few upstream fixes landed in the win32 printing code since 1.18.4 was released, but a build with all them cherry-picked still reproduces the problem. A build with _cairo_dwrite_scaled_font_init_glyph_surface reverted back to it's previous state does fix the problem, however.
https://treeherder.mozilla.org/jobs?repo=try&revision=7beacf87e5f17392691bfca3dd299a07bc8c36d8

Comment 5

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

The bug is marked as tracked for firefox152 (nightly). However, the bug still isn't assigned.

:bhood, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Does skpdf fix this? (printing.experimental.skpdf=true)

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Still reproducible after setting that pref (doesn't exist by default in about:config) and restarting the browser.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Sorry, print.experimental.skpdf, ugh!

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Still reproducible after flipping that pref in about:config and restarting.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

For clarity, I'm using the "Microsoft Print to PDF" printer rather than the "Save to PDF" option from the print dialog. The former matches what I see printed on my actual printer.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Ah yeah so this depends on rewriting PrintTargetWindows to use SkPdf.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

https://searchfox.org/firefox-main/rev/a353242aeafd56b2c21a2c0672ecb51ea1b81142/gfx/thebes/PrintTargetWindows.cpp#48-50

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Attachment: WIP: Bug 2036587 - Revert _cairo_dwrite_scaled_font_init_glyph_surface to pre-1.18.4 implementation.

The 1.18.4 rewrite of this function (using IDWriteGlyphRunAnalysis directly)
has multiple bugs that surface during PDF print rasterization fallback,
producing pages with all glyphs missing. Revert to the pre-1.18.4 GDI-based
implementation, which uses _dwrite_draw_glyphs_to_gdi_surface_gdi and
_cairo_compute_glyph_mask. Use the variations-aware scaled_font->dwriteface
field added in 1.18.4 so variable-font axis values are still honoured.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

I'm not saying this is the patch we should take, but I'm attaching it for posterity at least. As mentioned in comment 4, this does fix the regression albeit at the cost of being yet another relatively heavy revert in our Cairo patch stack.

Comment 15

[Jonathan Kew [:jfkthame]]

Interestingly, AFAICS it seems that _cairo_dwrite_scaled_font_init_glyph_surface is rasterizing the glyphs as expected; inspecting surface_data at the end of that function, I'm seeing the expected bitmaps. It's not clear to me why they're failing to appear in the output.

Comment 16

[Jonathan Kew [:jfkthame]]

Attachment: Bug 2036587 - Don't set the component-alpha flag when generating glyph surfaces. r=#gfx-reviewers

Comment 17

[Jonathan Kew [:jfkthame]]

Ryan, the above patch seems to resolve the missing text in my testing, with your PDF as well as some other examples. I'll do a bit more testing tomorrow, but you might also like to give it a whirl.

This doesn't address the fact that we end up with the page rendered as a rasterized bitmap, so the text is not searchable/selectable; that's a separate issue (and I assume was also the case prior to the cairo update). Not all documents exhibit that issue; it depends on the particular graphics features used during the rendering.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Yeah, I can confirm that older Firefox versions also end up with a rasterized bitmap when printing that particular PDF.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Jonathan's patch also works on my machine.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Is it possible to create a test for this?

Comment 21

[Jonathan Kew [:jfkthame]]

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

Is it possible to create a test for this?

Our "printing" tests normally use the Save as PDF backend, rather than an actual Windows printer driver, so they don't exercise the same code path. So I'm not sure how readily we can test this in CI, but I was intending to try and look into it.

(I'm going to go ahead and land the patch, even though we don't currently have test coverage for it, so that at least it's in Nightly for manual verification.)

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9e0da8537f35
https://hg.mozilla.org/integration/autoland/rev/021232917efa
Don't set the component-alpha flag when generating glyph surfaces. r=gfx-reviewers,lsalzman

Comment 23

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/021232917efa