Open Bug 1269023 Opened 8 years ago Updated 8 months ago

poor print quality from pdf on 332-2012.pdf

Categories

(Firefox :: PDF Viewer, defect, P3)

45 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: RossBoylan, Unassigned)

References

(Depends on 3 open bugs)

Details

(Whiteboard: [pdfjs-integration][pdfjs-printing])

Attachments

(1 file)

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.
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Is it possible to scan  and attach (as PDF) the 1st page of the print output?
Component: Untriaged → PDF Viewer
(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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Priority: -- → P3
Whiteboard: [pdfjs-c-integration][pdfjs-d-printing]
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.

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

Flags: needinfo?(bdahl)
Flags: needinfo?(bdahl)

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

(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 :)

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...

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.

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!

Depends on: 1639844
See Also: → 1274502
Whiteboard: [pdfjs-c-integration][pdfjs-d-printing] → [pdfjs-integration][pdfjs-printing]

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.

Severity: normal → S2

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.

Flags: needinfo?(mcastelluccio)
Flags: needinfo?(bdahl)

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.

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.

Flags: needinfo?(mcastelluccio)
Flags: needinfo?(bdahl)

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

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

See Also: → 1772225

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.

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.

Depends on: 1774615
Depends on: 1746222
See Also: → 1774631
See Also: 1274502

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

Summary: poor print quality from pdf → poor print quality from pdf on 332-2012.pdf

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.

(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?

Flags: needinfo?(cdenizet)

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 ?

Flags: needinfo?(cdenizet) → needinfo?(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.

Flags: needinfo?(dariush)

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 :)

Flags: needinfo?(cdenizet)

(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.

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?

(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

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.

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.

Flags: needinfo?(cdenizet) → needinfo?(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.

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: