1269023 - poor print quality from pdf on 332-2012.pdf

Status: NEW

(Firefox :: PDF Viewer, defect, P3)

Description

[Ross Boylan]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160420142932

Steps to reproduce:

Clicked on a link to http://support.sas.com/resources/papers/proceedings12/332-2012.pdf, a pdf document.
The document displayed within my browser; I hit the print icon.
The result was blurry.
Saved the pdf file from within the browser.
Via the download icon in the browser, opened the resulting file.
Adobe Acrobat Reader DC 2015.010.20060 was the viewing program.
Printed from it.  Results are clear.

The document, according to Adobe Reader has a page size of 8.5 x 11 in.


Actual results:

The printout from FF was blurry (the characters look a bit as if rendered by a dot matrix printer) but seemed to have the entire page.
The printout from Adobe Reader was clear, though the banner at the top of the page was mostly cut off.

The FF output is vertically compressed relative to Adobe's, by about 5 lines for the whole page.

The printer, a Xerox WorkCenter 7855, used 8.5 x 11 in paper.


Expected results:

Clear results with the whole page for both methods.

Comment 1

[Loic]

Is it possible to scan  and attach (as PDF) the 1st page of the print output?

Comment 2

[Ross Boylan]

(In reply to Loic from comment #1)
> Is it possible to scan  and attach (as PDF) the 1st page of the print output?

Yes, but it will take a few days since it's at work.  Also, I'm not sure whether the scan will have sufficient detail to see what's going on.
Ross

Comment 3

[YF (Yang)]

I see the blurred edges of text in files with "Microsoft Print to PDF" or "XPS Document Writer" in Fx47b1 & 49.0a1 2016-04-30 on Win10. Have a clear edge of the text with the same virtual printer in Edge.

Comment 4

[Ross Boylan]

Attachment: Document as printed from FF (p. 1) and Adobe (p. 2)

Here is a 600 dpi scan of the page printed directly from Firefox and via Adobe Reader.  The former is blurry, the latter is not.  Even at 600 dpi I don't think the difference shows up too well, and in fact the scanning seems to have corrected some of the problems in the original for FF.  For example, the "x" in the second word of "Inherently, mixed" is a little faint on the printed page, but looks about as dark as the other characters in the scan.

This was scanned on the same device that I used to print the documents originally; I specified text with solid ink as the source.

Comment 8

[Ross Boylan]

The bugs marked as duplicates of this one do not all describe the same problem.  They are all about poor print quality, but poor in different ways.  It is not clear to me that fixing one will fix the others.

Comment 9

[Bernard Gray]

This bug is still relevant, the quality of print from the pdfjs viewer is so far subpar compared to other pdf viewers.

I've taken a photo rather than a scan of two documents, one printed from the builtin chrome pdf viewer, and the other from the firefox pdf viewer.

Here's a side by side comparison at 100% res which really highlights the difference:
https://drive.google.com/file/d/1WPDSX9fnphc8d-6Ju4rDps0NGXXP6qI1/view?usp=sharing

It looks as though firefox is rendering the page as a bitmap first, where chrome is sending proper text/vector objects to the printer.

Here's the full photo of the firefox print:
https://drive.google.com/file/d/1vZbKATS-auakLfFwY_6qkHo9hqIohK_D/view?usp=sharing

Here's the full photo of the chrome print:
https://drive.google.com/file/d/1TbmdWTKdGyFEXV56gRrlV6FMeab5TQvZ/view?usp=sharing

Comment 10

[Brendan Dahl [:bdahl]]

There's some work improving the printing backend, hopefully once that's addressed we can fix this.

Comment 11

[Bernard Gray]

(In reply to Brendan Dahl [:bdahl] from comment #10)

There's some work improving the printing backend, hopefully once that's addressed we can fix this.

awesome news! Thanks for getting back to me -

#844090 is another longstanding printing bug affecting us - if it's being looked at as part of this process as well, I'm sure there are a lot of people watching that bug that would appreciate a similar update :)

Comment 12

[CeDeROM]

Hello from year 2021 the Firefox 85 printouts of PDF still sux on FreeBSD (12) - they are blurry and poor quailty unlike other system pdf viewers. Please fix :-)

Comment 13

[gismocz]

I can confirm same problems as described before prevail in 2021. Quailty of the PDF printed out directly pro Firefox using <Ctrl+P> is far worse compared to downloading the PDF and printing with Okular.

OS: Fedora 33, 5.10.14-200.fc33.x86_64
Firefox: 85.0.1
Okular: 1.11.1

Comment 14

[omikron]

I've been having the same problem for a LONG time.

Where it gets particularly nasty is trying to print shipping labels to a thermal printer. Most websites output the label to PDF, but printing directly from FF results in unreadable return addresses. Printing directly from any other application is fine.

It is exceptionally disappointing to be still running into this bug...

Comment 15

[Peter Bieringer]

I got hit with same problem, currently using firefox-89.0.2-2.fc34.x86_64 (Fedora Linux) - while opening the document in "evince" and print with expected resolution, the Firefox internal PDF viewer and way of printing results in somehow ugly printout, looks like same resolution as on screen.

And reading that source
https://www.gyrocode.com/articles/how-to-increase-print-quality-of-pdf-file-with-pdf-js-viewer/ assume the printout is 150 dpi (if ever)

Is this intended and will this stay or is there any secret toggle that Firefox will use for printout of PDF e.g. 600 dpi like "evince" does?

Like written in posting above, printing of shipping labels is dangerous, resolution potentially too bad for scanners.

Current "about:config":
pdfjs.renderer = canvas

found an interesting article btw regarding the support level of pds.js: https://www.pdftron.com/blog/pdf-js/guide-to-pdf-js-rendering/

In addition, the time of printing via Firefox -> internal print dialog or system print dialog is much longer than opening the document in "evince" and print from there (using same printer) - for unknown reason so far.

Comment 16

[or.dodson.evan]

I'm currently experiencing this issue as well on a toner black-white brother printer (HL-L2370DW). Increasing the print quality from the print menu or the printer resolution does not fix the issue. Only downloading the file and printing from another program solves this. Really distracting reading from blurry text with a small font. Please fix this!

Comment 23

[Julian Sikorski]

I have just noticed this with firefox-96.0.3-1.fc35.x86_64. Downloading the document, opening it with evince-41.3-1.fc35.x86_64 and printing it produced much higher quality. I unfortunately cannot share pictures as the document in question is confidential.

Comment 24

[omikron]

Marco or Brendan, can we get this thing bumped up to P2?

This is more than just "nice to have".

This bug has been negatively impacting a core piece of functionality, printing from PDF, for over six years. I understand it may not matter for "normal" documents, but it makes printing shipping labels extremely difficult or unreliable. More an more folks are shipping on their own and it is not reasonable to consider this an edge case.

I suspect most people don't even realize it's happening because at first glance it "looks" okay but it's not immediately clear that the barcode readability is severely degraded. There's likely a good quantity of tracking scan failures due to this.

Comment 25

[omikron]

I would highlight that printing shipping labels to thermal printers is one of the few reasons I have to have a third-party PDF reader installed, which often presents a security risk.

This is an issue beyond just convenience. No other browser or platform has this problem.

Comment 26

[Marco Castelluccio [:marco]]

You might notice some recent activity in this bug and the recent bump of the severity. It isn't an easy fix, but we are planning to work on it soon.

Comment 27

[Julian Sikorski]

Another point to consider is small text. I noticed this because on the document I printed small text was no longer legible.

Comment 28

[omikron]

I did notice the recent bump of the severity. It should have been S2 when it was opened, not six years later.

My request to bump the priority up has to do with the fact that this has been open for over SIX YEARS.

A PDF rendering bug that has been breaking functionality and usability has been open for six years. Look at all of the duplicate tickets that were linked back to this one. I understand it may not be an "easy" fix, but at some point there has to recognition that users have waited long enough.

Comment 29

[Marco Castelluccio [:marco]]

This is not a forum but a bug tracker, please stop commenting with non-constructive criticism.

Comment 31

[Jeff Muizelaar [:jrmuizel]]

I can reproduce the rasterization happening when printing http://support.sas.com/resources/papers/proceedings12/332-2012.pdf with "Microsoft Print to PDF". I suspect that there's something specific about this PDF that's causing rasterization because https://bugzilla.mozilla.org/attachment.cgi?id=9279413 prints without rasterization.

Comment 32

[Jeff Muizelaar [:jrmuizel]]

Running mutool trace on http://support.sas.com/resources/papers/proceedings12/332-2012.pdf, one thing that immediately stands out is that all of the content is wrapped in a <group bbox="0 0 612 792" isolated="1" knockout="0" blendmode="Normal" alpha="1">. It seems like this could be the cause of the rasterization.

Comment 33

[Jeff Muizelaar [:jrmuizel]]

I checked some more things. http://support.sas.com/resources/papers/proceedings12/332-2012.pdf rasterizes completely with "Microsoft Print to PDF", only the green areas with "Save to PDF" and no rasterization with "Microsoft Print to PDF" in Chrome

Comment 34

[dariush]

Please see the following example. It is not possible to print German e-stamps with Firefox. Example is generated using "Print to PDF" function, looks the same on paper (to my surprise at the post office...)

original
firefox

Interestingly enough, they look the same in Firefox, but I think you will have no problem spotting the difference in any other PDF viewer (or printed)
screenshot

Hope this helps.

Comment 35

[Marco Castelluccio [:marco]]

(In reply to dariush from comment #34)

Please see the following example. It is not possible to print German e-stamps with Firefox. Example is generated using "Print to PDF" function, looks the same on paper (to my surprise at the post office...)

original
firefox

Interestingly enough, they look the same in Firefox, but I think you will have no problem spotting the difference in any other PDF viewer (or printed)
screenshot

Hope this helps.

Is this the same case as bug 1774615?

Comment 36

[Calixte Denizet (:calixte)]

Is this the same case as bug 1774615?

I don't think so, I'd say it's a dup of 1779202.
:dariush, are you printing on Mac ? if yes what is the Firefox version ? if it's lower than 105, could you try with either 105 or 106 to see if you can reproduce the issue ?

Comment 37

[dariush]

(In reply to Calixte Denizet (:calixte) from comment #36)

Is this the same case as bug 1774615?

I don't think so, I'd say it's a dup of 1779202.
:dariush, are you printing on Mac ? if yes what is the Firefox version ? if it's lower than 105, could you try with either 105 or 106 to see if you can reproduce the issue ?

Sorry for the late response.
I'm now on 106 and the issue seems mostly fixed. The PDF is still low-quality but it's now slightly blurred instead of completely broken, which is fine for my use-case (printing e-stamps). Please see the screenshot for more information, bottom is Firefox print-to-pdf.

Comment 38

[Bernard Gray]

I believe this can be closed now - I've compared the print output from Chrome and Firefox 110 here:
https://drive.google.com/file/d/14eHKub0yw27HtOAFC_cFy5c_AulvXe96/view?usp=sharing

Compared to how it looked 3 years ago:
https://drive.google.com/file/d/1WPDSX9fnphc8d-6Ju4rDps0NGXXP6qI1/view?usp=sharing

This quality is perfectly adequate for printing barcodes etc, and the differences between the two are not enough to keep this bug open imo

Thanks for all the work mozilla/firefox team, very much appreciated :)

Comment 39

[Peter Bieringer]

(In reply to Bernard Gray from comment #38)

I believe this can be closed now - I've compared the print output from Chrome and Firefox 110 here:
This quality is perfectly adequate for printing barcodes etc, and the differences between the two are not enough to keep this bug open imo
Thanks for all the work mozilla/firefox team, very much appreciated :)

Can confirm, since some releases it has improved a lot.

Comment 40

[Ross Boylan]

I attempted to check with the original document I reported, but seem to have run into another problem: print from the FF preview is not working for me. I assume that's an unrelated problem (getting to the printer is a bit exotic: it's being forwarded from my home system to the server via remmina)--printing from other programs (specifically Foxit PDF Editor and notepad) works fine.

-->Could anybody else try printing http://support.sas.com/resources/papers/proceedings12/332-2012.pdf with current FF and see how it looks?

Comment 41

[Bernard Gray]

(In reply to Ross Boylan from comment #40)

-->Could anybody else try printing http://support.sas.com/resources/papers/proceedings12/332-2012.pdf with current FF and see how it looks?

Here you go:

Firefox 100: https://drive.google.com/file/d/1Z2hdYLOSp1tmtd-zF0V5vmt8JV4nYQs4/view?usp=sharing

Firefox 110: https://drive.google.com/file/d/1W-8x0qWCpTJZoCn32gWOFLNwTtgAeevH/view?usp=share_link

Chrome: https://drive.google.com/file/d/1tBejxJs2jJvxQTOkxhemXJeDChCIr1yL/view?usp=sharing

Still quite a bit of difference between the font weight used in chrome and firefox, but the quality of font rendering (kerning, and sharpness) is significantly improved

Comment 42

[Ross Boylan]

Thank you. They all look a bit marginal to me, but that might just be the resolution of the photo.

I was able to print from FF 111.0.1 running on a local MacOS, and the document looked good that way--really about as good as the printout from the Preview application on the same machine (FF was better in that, as in my original report, the non-FF route clipped part of the title banner on p. 1, while the FF version did not). Since the original problem was on MS-Windows, this isn't quite proof, but it's a good sign.

As a reminder, my original concern was with reading ease for humans, not for bar code scanners.

It might be meaningful that the printout was much slower from FF than from Preview; in particular I wonder if FF is still rasterizing, but doing so at a higher resolution (presumably that of the printer).

At any rate, thanks to the developers for whacking this problem.

Comment 43

[Marco Castelluccio [:marco]]

Great to hear this is much better than before!

We'll keep this bug open to completely avoid the rasterization. Jonathan, would it be possible to have telemetry to know how often we are rasterizing when printing a PDF? I'd like to figure out if we still need to consider this as S2.

Comment 44

[Jonathan Kew [:jfkthame]]

(In reply to Marco Castelluccio [:marco] from comment #43)

would it be possible to have telemetry to know how often we are rasterizing when printing a PDF?

My intuition is that it'd be tricky to assess.... there'll be various places within cairo where the win32 printing surface may decide an operation is "unsupported" and has to be handled by falling back to internal rasterization, but I'm not sure how we'd usefully deal with the granularity of this. It might be just a small, unimportant element that's being rasterized, or might be an entire page. Would we only record if the area being rasterized is larger than... some arbitrary size?

(In reply to Bernard Gray from comment #41)

Firefox 110: https://drive.google.com/file/d/1W-8x0qWCpTJZoCn32gWOFLNwTtgAeevH/view?usp=share_link

Chrome: https://drive.google.com/file/d/1tBejxJs2jJvxQTOkxhemXJeDChCIr1yL/view?usp=sharing

Still quite a bit of difference between the font weight used in chrome and firefox, but the quality of font rendering (kerning, and sharpness) is significantly improved

There's another interesting thing here, actually. It's not just about font rendering (darkness/weight, sharpness, etc); there is also some kind of font substitution happening, such that the Chrome and Firefox printouts show a different font being used for some of the text.

It's perhaps easiest to see this on the headings like ABSTRACT and INTRODUCTION, where the original PDF looks like it's using Arial, and this is also what I think Chrome's printout shows, but the photo of Firefox output looks like it is instead using Helvetica. Compare for example the shape of the right leg of "R", which is distinctively different between the two fonts. Another visible difference is at the tips of the "C", where Helvetica has them cut horizonally, while Arial's tips slant distinctly outwards. Oh, and compare the "G" in IMPROVING PERFORMANCE.

So I wonder where in the process this substitution is happening, and why. It seems to apply to the bold headings, but not the body text. Weird.

Comment 45

[Ross Boylan]

I noticed a couple things trying my original test document with FF 130.0, compared to the output from a regular PDF viewer (FoxIt).
All comparisons are for p. 1. There is no change in the overall conclusion that FF output is much improved from that of the original report, but still not quite as good as printout from dedicated pdf tools. The latter produce characters that are sharp and clear, while FF produces characters that are slightly fuzzy and appear to have somewhat variable black levels. And FF cuts off the top of the page.

1. The printout from FF was larger, both vertically and horizontally. If the ABSTRACT heading is aligned, the last heading, MAKE CHANGES TO THE RUNNING ENVIRONMENT, from FF lines up roughly with the text line below that heading (starting "The following changes") from the regular output. So FF has gained almost 2 lines (the text line and the vertical gap after the heading). This is the reverse of the situation in my original report, in which FF output was vertically compressed relative to the regular output. The page number is physically lower on the page for FF.

2. The green heading at the top is cutoff for FF and only a small bit of the text in it is visible. The regular output shows the complete green banner and whitespace above it, but the very bottom of the characters in the green banner is cut off. The cutoff is small; for example in the small "o" the lower horizontal section (imagine a vertical centerline through the middle and consider the part with ink on the bottom) is missing perhaps the bottom 1/3. When viewed on the screen it looks fine.

Test was on Windows Server 2019 Standard, Version 1809 printing to Xerox AltaLink C8005 with drivers provided by Xerox. The two conditions were

"Firefox": Go to http://support.sas.com/resources/papers/proceedings12/332-2012.pdf and print from FF. This used Xerox's default Windows driver.

"regular": Download the same document with FF and open in Foxit PDF Editor Pro 13.1.3.22478. This test used Xerox's Postscript Windows driver, and went to a different physical printer, same model.

Unlike the previous report (https://bugzilla.mozilla.org/show_bug.cgi?id=1269023#c44), I did not notice any difference in the fonts. The tips of the C slant outwards, so I guess that's Arial.