811002 - Low Quality Print Output of PDFs (win)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Brendan Dahl [:bdahl]]

Attachment: part 1 - v1

Part 1 (fixed with patch):
Printing a pdf with pdf.js on windows and linux results in low quality(blurry) output.  Also, when printing from PDF to PDF/XPS text becomes rasterized and is no longer selectable, whereas on OSX text remains crisp and is still selectable.

Part 2 (broken from part 1 patch):
Part 1 can be fixed on windows with the attached patch, but then images in PDF's no longer show up.

Background on pdf.js printing:
When pdf.js draws images we first draw them to a separate canvas and then draw them to the main page canvas.  During the mozPrintCallback the main canvas context is a win32 printing surface and the image canvas appears to be a d2d surface.  I've tried to step through most of the drawImage canvas code and can see no obvious problems/warnings/errors.  I'm guessing the issue is drawing a d2d surface on to a recording surface, but I don't really know where this is going wrong.  I also looked at XPS output and all the text is there but no images are in the XML.

I'm hoping someone more familiar with graphics can look into this and help the pdf.js team get better print output.

Test PDF:
http://www.education.gov.yk.ca/pdf/pdf-test.pdf

Comment 1

[Brendan Dahl [:bdahl]]

Note that we currently have a less than ideal workaround to render the canvas at twice the resolution and use css scaling, see: https://github.com/mozilla/pdf.js/pull/2381/files .

Comment 2

[Julian Viereck]

Not sure, but here is some stuff I figured out when I've looked at the problem:

I've asked on the cairo mailing list about rasterizing a surface:

  http://lists.cairographics.org/archives/cairo/2012-May/023084.html

Maybe also this is useful:

  https://bugzilla.mozilla.org/show_bug.cgi?id=691061#c14

Brendan, have you tried to set a breakpoint in the cairo code that rasterizes the record surface to an image and tried to figure out why the rasterization is happening?

Comment 3

[Brendan Dahl [:bdahl]]

Julian,
The ransterization appears to be fixed with my attached patch, but as mentioned drawing images no longer works after that.

Comment 4

[Thomas D. (:thomas8)]

This bug, combined with other pdf.js printing bugs, renders pdf printing completely useless, which is clearly a substantial loss of functionality. Having inbuilt pdf-viewer is nice, but these major flaws are entirely unacceptable:
- pdfs print in low quality (this bug)
- pdfs print with browser's header & footer settings (bug 743252)
- pdfs are scaled down in size before printing (do we have a bug for that?)
Not sure how these things managed to escape QA when the feature landed?

These should be fixed asap to avoid poor publicity and support being rolled over by respective complaints and bug reports.

Comment 6

[Thomas D. (:thomas8)]

Can somebody set whiteboard to [pdfjs-c-feature] or [pdfjs-d-printing] as appropriate, and/or point to a reference where these flags are explained?

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #4)
> - pdfs print in low quality (this bug)
> - pdfs print with browser's header & footer settings (bug 743252)
> - pdfs are scaled down in size before printing (do we have a bug for that?)
I filed bug 847049 for that.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #6)
> Can somebody set whiteboard to [pdfjs-c-feature] or [pdfjs-d-printing] as
> appropriate, and/or point to a reference where these flags are explained?

Comment 9

[Thomas D. (:thomas8)]

I see a lot of merry-go-round pointers between various pdfjs printing bugs on bmo and github, but is there any commitment to actually fixing them? Any work going on? If yes, where?

Or are we going to wait until more frustrated consumers start to simply switch off pdfjs and return to Adobe Reader Plugin instead, like the University of Helsinki who recommends just that because of pdfjs printing problems?

https://www.cs.helsinki.fi/en/news/77185

Comment 10

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #6)
> Can somebody set whiteboard to [pdfjs-c-feature] or [pdfjs-d-printing] as
> appropriate, and/or point to a reference where these flags are explained?

I waited two months for somebody to set these flags and point out where they are explained, but there was no response. So well, I'll just set them myself, some flags are better than none for tracking purposes.

Comment 11

[Brendan Dahl [:bdahl]]

Attachment: test case to highlight issue with patch

Comment 12

[John Dennis]

Please revert to the previous behavior! Whatever pdfjs is doing is horrible, I suffered with terrible PDF printing from Firefox for months now until I finally got so frustrated and decided to do something about it, I didn't understand what changed to make it so bad all of a sudden. Which lead me here.

Comment 14

[Dave Hylands [:dhylands]]

Attachment: Scan showing low-res

The half-page on the left was printed using PDF-js, the half page on the right was printed using acroread.

Comment 15

[Dave Hylands [:dhylands]]

My printer is an HP Color LaserJet CP2025, which claims 600 dpi resolution.

Comment 16

[david.leibovic]

Hello,

I am an engineer at http://etsy.com/ on the Shipping Labels team. We have 200,000 users on Etsy who are onboarded to print shipping labels. These users purchase ~40,000 shipping labels per day. Firefox is the desktop browser of choice for 15-20% of our users.

When a shipping label is purchased, it is downloaded as a PDF. The user prints the PDF and affixes it to their package.

Printing PDFs using Firefox is a constant struggle. Headers and footers are often left on by default, which can invalidate the label. Furthermore, the printed output of PDF.js is blurry, which can lead to inaccurate barcode scans at the post office.

When users write to our support team complaining about blurry PDF printouts from Firefox, we tell them that they can download the PDF and print it from Adobe Reader, or they can switch browsers.

Please see examples here: http://fastcheetahs.com/FF_bug_811002.zip
In this ZIP you will find several files:
CanadaPost_Adobe.pdf - A scanned Canada Post shipping label printed using Adobe Reader. It is clear & crisp.
CanadaPost_FF.pdf - A scanned Canada Post shipping label printed using Firefox (PDF.js). It is blurry.
CanadaPost_Original.pdf - The original Canada Post shipping label PDF file.
USPS_Adobe.pdf - A scanned USPS shipping label printed using Adobe Reader. It is clear & crisp.
USPS_FF.pdf - A scanned USPS shipping label printed using Firefox (PDF.js). It is blurry.
USPS_Original.pdf - The original USPS shipping label PDF file.

Hopefully this bug can be fixed soon, and we can stop turning users away from Firefox!

Best regards,
David Leibovic

Comment 17

[Andreas Gal :gal]

Brendan any progress on this?

Comment 18

[Brendan Dahl [:bdahl]]

(In reply to Andreas Gal :gal from comment #17)
> Brendan any progress on this?

No, I've been trying to get someone from gfx to take a look. I could take another stab at trying to figure it out, but I think someone with more knowledge of gfx may be able to figure out quicker why images don't work the the above patch applied.

Comment 19

[Andreas Gal :gal]

Milan, please investigate.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Brendan Dahl [:bdahl] from comment #3)
> Julian,
> The ransterization appears to be fixed with my attached patch, but as
> mentioned drawing images no longer works after that.

The patch is windows only?  Is the rasterization now working for Linux?  But, let's sort out Windows first - Bas, you're the one with the windows machine at the work week - could you take a quick peek?  Otherwise, it'll have to wait until we're back in the office.

Comment 21

[John Dennis]

By any chance does the code depend on the poppler library? Similar issues are reported in this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=755082

Comment 22

[Bas Schouten (:bas.schouten)]

I've gotten some idea of what's going on here. There appears to be a bug inside the Win32 Printing surface. I'm investigating further to try and figure out how to fix it.

Comment 23

[Bas Schouten (:bas.schouten)]

I've rootcaused the bug. The patch on this bug is good, with that patch will make us use the Win32 printing surfaces as we should. There's a bug however in cairo's Win32 printing surface that I've rootcaused as well, what's happening here is that while replaying the paints that draw the images into the surface the ctm of the parent surface is not taken into account. Cairo's backends calls are in device space, with the pattern transform being adjusted for the CTM. This adjustment is not occurring in the replay that the cairo win32 surface does.

I've got a hack that fixes this but I'm still working on the proper solution.

Comment 24

[Bas Schouten (:bas.schouten)]

Comment on attachment 680693 [details] [diff] [review]
part 1 - v1

Review of attachment 680693 [details] [diff] [review]:
-----------------------------------------------------------------

I will land this -after- I land the Win32 printing backend fix.

Comment 25

[Bas Schouten (:bas.schouten)]

Attachment: bug811002

This is all pretty convoluted so I expect bugs might show up in other places. However I believe this fix is at the very least correct and with these two patches it will print properly on windows.

Comment 26

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 822279 [details] [diff] [review]
bug811002

Review of attachment 822279 [details] [diff] [review]:
-----------------------------------------------------------------

Adrian how do you feel about this?

Comment 27

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7aec4c2156d5
https://hg.mozilla.org/integration/mozilla-inbound/rev/f359db89c13b

Comment 28

[david.leibovic]

FYI, this is also a bug on Mac OS. I'm not sure if this is the proper place to make that comment, or if there is a separate bug report open for Mac OS. I assume that this patch will not fix it on Mac OS.

Comment 29

[Bas Schouten (:bas.schouten)]

(In reply to david.leibovic from comment #28)
> FYI, this is also a bug on Mac OS. I'm not sure if this is the proper place
> to make that comment, or if there is a separate bug report open for Mac OS.
> I assume that this patch will not fix it on Mac OS.

Correct, it will not. We should open a separate bug.

Comment 30

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/7aec4c2156d5
https://hg.mozilla.org/mozilla-central/rev/f359db89c13b

Comment 31

[Mike Hommey [:glandium]]

(In reply to Bas Schouten (:bas.schouten) from comment #29)
> Correct, it will not. We should open a separate bug.

It doesn't fix linux either, does it? (linux *is* in the bug title)

Comment 32

[u285178]

(In reply to Jeff Muizelaar [:jrmuizel] on PTO till October 21 from comment #26)
> Comment on attachment 822279 [details] [diff] [review]
> bug811002
> 
> Review of attachment 822279 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Adrian how do you feel about this?

I don't know. I haven't looked at the win32 backend for a couple of years. There have been some fixes for the 72ppi rasterization problem in cairo. I can't find them but I remember they were general fixes that fixed the problem for all backends.

Comment 33

[Thomas D. (:thomas8)]

Bas, does this bug fix it for Linux? (comment 31)

Does this bug fix bug 847049, namely that printed PDF output from FF is also shrinked in size? If the shrinking isn't fixed here, could you pls proceed with bug 847049 because that's equally annoying to a huge (private/business) userbase depending on correct PDF printouts from FF? Many documents will still be completely useless or unreadable if they don't print in exact size (e.g. smallprint, barcodes, matrix, anything meant to be scanned later).

Comment 34

[Bas Schouten (:bas.schouten)]

(In reply to Thomas D. from comment #33)
> Bas, does this bug fix it for Linux? (comment 31)

It should not affect Linux.

> Does this bug fix bug 847049, namely that printed PDF output from FF is also
> shrinked in size? If the shrinking isn't fixed here, could you pls proceed

It could very well be fixed, but I'm not sure, since this fix related to transforms as well as changing the surface types we use there's a chance it is.

> with bug 847049 because that's equally annoying to a huge (private/business)
> userbase depending on correct PDF printouts from FF? Many documents will
> still be completely useless or unreadable if they don't print in exact size
> (e.g. smallprint, barcodes, matrix, anything meant to be scanned later).

I cannot, I've seen no indication that the case for spending time on that bug is as strong as for this one. And as such I'm not in a position where I can allocate my time on that.

More importantly I do not believe that bug is necessarily in graphics code. Especially if the patch here doesn't fix it. Should this bug turn out to be inside graphics code then the choice to invest short-term engineering resources on it should be made in that bug.

Comment 35

[Julian Viereck]

(In reply to Bas Schouten (:bas.schouten) from comment #34)
> (In reply to Thomas D. from comment #33)
> > Bas, does this bug fix it for Linux? (comment 31)
> 
> It should not affect Linux.

Should the title of the bug be changed and a new bug for fixing the issue on Linux be openend?

Comment 36

[Milan Sreckovic [:milan] (needinfo for best results)]

I cloned it and bug 932289 covers the Linux case.

Comment 37

[david.leibovic]

I have created a new bug for the Mac OS case: https://bugzilla.mozilla.org/show_bug.cgi?id=932313