Pdf.js: Print is fuzzy/blurry

I'd guess it's because the pdf.js output is a canvas (one canvas per page, to be exact), which probably doesn't match 100% the printer resolution.

This happens to me, too.

• top = Firefox builtin PDF.js
• bottom = Adobe Acrobat

The print quality is simply unacceptable.
In addition, the builtin PDF.js generates a black border on the right and bottom sides, just as if it were from photocopying a smaller size sheet.

Any solution? i'm in a hotline and i have 200 users with this problem.

@BadFriend, @musiphil, what operating system you or your users use?

Same issue here on FFox 19 on WinXP to PostScript printer. The fine horizontal lines are dithered, while the vertical lines are fine. Headers and footers are fine as well.

I'm running Firefox 19.0 on Windows 7, and I printed those documents to a HP Color LaserJet CP4525 printer with PCL6.

FF19 + Win7 64bit + OKI561 via PCL6 on WSD Port or Adobe PDF (Adobe Acrobat 9.2.0)

left: Chrome Plugin
middle: Adobe Reader
right: Firefox pdf.js

Download PDF -> http://www.file-upload.net/download-7241349/offers-36.pdf.html

See also #2771. Quoting @brendandahl:

The low quality is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=811002 .

The upstream bug has been fixed. Is this still an issue with the latest versions of Firefox and PDF.js?

The upstream bug has been fixed. Is this still an issue with the latest versions of Firefox and PDF.js?

I think it was only fixed for Windows. There is a new bug filled for OSX (bug 932313) but I am not convinced it is valid (see my comment at https://bugzilla.mozilla.org/show_bug.cgi?id=932313#c2).

Until the issue is not fixed on Linux, I vote for keeping this bug open.

Is it fixed?
This demo page prints ok from firefox
http://mozilla.github.io/pdf.js/web/viewer.html
https://dl.dropboxusercontent.com/u/1383480/work/printing/2015-02-16%2011.29.52.jpg

from Chrome and Chromium print result is SO blurry, I can't find words to describe it
https://dl.dropboxusercontent.com/u/1383480/work/printing/2015-02-16%2011.29.58.jpg
I tried to set dpi for printer and PRINT_SCALE RATIO to 1, 3, 4, 8 - no effect
I tried latest version from github (8614c17) - same
(enviroment: Chrome, Chromium, windows 7)

Am I missing something?
Could you please review this and possibly suggest quick workaround?

@jonny64 thanks for reporting this! Unfortinate, I guess there is not much that can be done for Chrome/Chromium here. The better print quality in Firefox results by using a special API for printing that is available in Firefox but not in Chrome. Back in the days I proposed the API as a standard but there was not much interest and therefore it is still only available in Firefox.

:) @jviereck, well, ok, I should live with it
I tried Chrome internal viewer
It prints ok, but it's 'Save' brokes kiosk mode
(we need to print with preview from Chrome in kiosk fullscreen mode)

Fortunatly, I have some backgound with C some time ago
https://pdfium.googlesource.com/pdfium.git
Is it correct source for Chrome internal viewer?
Is it better to hide 'Save' from Chrome settings or when --kiosk command line is set?
Do you have any high level ideas where and how can I implement it?

This is still a bug on OS X and the latest Firefox Dev Edition, as far as I can tell, at least in some circumstances.

How to reproduce without a printer:

• Click "Print" in the PDF.js viewer.
• Click the "PDF" button.
• Choose "Save as PostScript…" (not "Save as PDF…")
• Open the saved .ps file in Preview.app.

Text is not selectable and, zooming in, the text is quite pixelated. Text looks great if you chose "Save as PDF…"

I tried increasing the default resolution in
web/app.js::beforePrint
<< var pageSize = this.pdfViewer.getPageView(0).pdfPage.getViewport(1);

var pageSize = this.pdfViewer.getPageView(0).pdfPage.getViewport(2);

and web/pdf_page_view.js::beforePrint
<< var viewport = pdfPage.getViewport(1);

var viewport = pdfPage.getViewport(2);

Printing is slower but quality has improved

Some improvements after #7677

Have there been any updates to this issue in the past 4 months? This is still noticeable on the latest version of pdf.js. I recently rolled out a deployment using pdf.js and now have documents printing with a fuzzy letters that weren't a problem with Chrome's native PDF reader.

You can reproduce this issue by printing from Mozilla's own demo page. I know it isn't a driver issue because it happens when you print to a PDF as well.

It looks like some people using pdf.js in production have had to bypass pdf.js entirely to work around this issue (example).

Currently, higher quality printing is not possible without greatly increasing memory usage, which most browsers won't take well. The canvas back-end cannot provide such functionality. There is a project open (https://github.com/mozilla/pdf.js/projects) to research using the prototype SVG back-end for high quality printing.

I have found the PDF.js has had acceptable print quality and fuzzy print quality depending on the version of Firefox installed so would like to take a look at what has changed between the versions I was able to print from. I have https://imgur.com/7Beh7MO, which is output from a direct print from left to right of Firefox 52, 47.0.2, and 42, with the first two at least being fresh updates. As shown, something changed in PDF.js between FF 47.0.2 and FF 52 releases that seems to have crapped up the quality, so if anyone has info on what bookmarks to look at to start with for those versions of Firefox, I wouldn't mind taking a look to start.

Looking at the Firefox repository versions of PDF.js, I see that 47.0.2 was version 1.4.121, which corresponds to commit 51f6aba (might be the commit after, which is be1e12d) and that Firefox 52 shipped with PDF.js 1.6.315, which is roughly commit c23f124. I am currently looking into diffing these commits, but the difference between them is probably 400 commits and any information on where printing lies would be very helpful.

As shown, something changed in PDF.js between FF 47.0.2 and FF 52 releases that seems to have crapped up the quality,

While it's certainly possible that a change in PDF.js is responsible, I wouldn't (at least initially) entirely discount the possibility that the issue could be related to e.g. graphics/printing code in other parts of Firefox.
It may be helpful, and perhaps even quicker, to use http://mozilla.github.io/mozregression/ to try and find a regression range.

Does the print button inside of PDF.js even use Firefox to print? My
assumption based on the fact that the plugin is available in other browsers
is that there wouldn't be any issues related to how the underlying browser
handles printing. This is also supported by the print processing dialogue
listing PDF.js rendering as a task to send the data to the printer. I will
do some additional testing and try and run PDF.js as a plugin and test
different versions of possible to see if that changes anything.

On Mar 14, 2017 9:58 AM, "Jonas Jenwald" notifications@github.com wrote:

As shown, something changed in PDF.js between FF 47.0.2 and FF 52 releases
that seems to have crapped up the quality,

While it's certainly possible that a change in PDF.js is responsible, I
wouldn't (at least initially) entirely discount the possibility that the
issue could be related to e.g. graphics/printing code in other parts of
Firefox.
It may be helpful, and perhaps even quicker, to use
http://mozilla.github.io/mozregression/ to try and find a regression
range.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/pdf.js/issues/2750#issuecomment-286428765,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOZHcyFJnLjI8MhAXspe-SIikmMA7YWOks5rlpzwgaJpZM4AcblL
.

--
Please click to read Notices:
http://www.mediweightlossclinics.com/sig/ Confidential Communication
http://www.mediweightlossclinics.com/sig/ Educational Purposes Disclaimer
http://www.mediweightlossclinics.com/sig/ Franchise Disclosure Statement

Previously, we used the Mozilla-specific mozPrintCallback wherever we could if it was supported, i.e., in add-on and non-add-on versions in the Firefox browser, as it presumably allowed us to print with less memory consumption and higher quality. However, we tried to reduce the usage of that because it's Firefox-specific and sometimes buggy, so now we only use it in the Firefox add-on (https://github.com/mozilla/pdf.js/blob/master/web/firefox_print_service.js).

In general, we now render the canvases and print them using the regular browser-defined printing logic, so I think the issue may either be in changed canvas scaling/font rendering code or a browser bug.

Refer to https://github.com/mozilla/pdf.js/commit/c09f634bb6c713f6dc36628145788c88e60448e0 for the majority of that change. You might want to check if there is a difference in printing quality from Firefox with and without the add-on.

Since https://github.com/mozilla/pdf.js/commit/c09f634bb6c713f6dc36628145788c88e60448e0 there is now renderPage function in web/viewer.js and print resolution is hard-coded in there as 150 DPI.

function renderPage(activeServiceOnEntry, pdfDocument, pageNumber, size) {
  var scratchCanvas = activeService.scratchCanvas;
  var PRINT_RESOLUTION = 150;
  var PRINT_UNITS = PRINT_RESOLUTION / 72.0;

To change print resolution to 300 DPI, simply change the line below.

var PRINT_RESOLUTION = 300;

According to the release tags, all PDF.js versions from 1.7.x to 1.10.x should have that ability now. I am surprised this is not documented anywhere.

Ideally there should be ability to change print resolution from query parameters instead of modifying web/viewer.js.

See How to increase print quality of PDF file with PDF.js viewer for more details.

If @mpryvkin's fix is legitimate, this should definitely be exposed as an option in about:config.

Could this be parameterized?

I tried increasing the default resolution in
web/app.js::beforePrint
<< var pageSize = this.pdfViewer.getPageView(0).pdfPage.getViewport(1);

var pageSize = this.pdfViewer.getPageView(0).pdfPage.getViewport(2);

and web/pdf_page_view.js::beforePrint
<< var viewport = pdfPage.getViewport(1);

var viewport = pdfPage.getViewport(2);

Printing is slower but quality has improved

it works!

The generic viewer now exposes the printResolution app option thanks to #10854 so the pre-built viewer does not have to be modified for this anymore. Note that increasing the print resolution, while improving print quality, might make printing slower and/or the browser less responsive, but this is now a trade-off that viewer users can make themselves.

@timvandermeij Thank you for the update! To clarify, are you talking about "users" as in "users of the pdf.js library", or as in "users of Firefox"? I fall in the latter category (and I believe this bug is concerned with users of Firefox), and am trying to figure out whether those AppOptions are exposed in Firefox in any way.

Update: I believe @timvandermeij is referring to "users of the pdf.js library". I also believe the AppOptions are exposed in Firefox through about:config, but not automatically (i.e., someone probably has to modify the firefox code to enable it), as most but not all AppOptions exist there. pdfjs.cursorToolOnLoad is in about:config, but not defaultUrl nor disableHistory, presumably because these don't make sense in the Firefox context.

@raztus Yes, I meant users of the library. Firefox builds were left out of that scope (https://github.com/mozilla/pdf.js/pull/10854#discussion_r287325125) because it's not easy to tell what happens with e.g., browser responsiveness and memory usage if you increase this value. If we get more feedback on that, I'm not against considering making the preference available for Firefox (mozcentral) builds as well.

@timvandermeij Thank you and @kleins05 for this improvement. I have updated my post regarding this feature.

Am I correct in assuming that with this update print resolution can be set using the code below?

document.addEventListener('webviewerloaded', function() { PDFViewerApplicationOptions.set('printResolution', 300); });

Yes, I think you're correct. The webviewerloaded event is indeed the right event to listen to for setting app options; see:
https://github.com/mozilla/pdf.js/blob/c91f437eaaff79b660805e020f4fa9d4a2a7fe65/web/viewer.js#L208-L210
After that point PDFViewerApplicationOptions should always be available. I haven't tried this particular snippet, but from inspection it looks good and you can try it out by checking out the latest master branch code, adding that snippet and checking if the print quality improves.

@raztus Yes, I meant users of the library. Firefox builds were left out of that scope (#10854 (comment)) because it's not easy to tell what happens with e.g., browser responsiveness and memory usage if you increase this value. If we get more feedback on that, I'm not against considering making the preference available for Firefox (mozcentral) builds as well.

@timvandermeij I would love to help provide some of that feedback. After all, about:config is already a warranty-voiding area ;) How can I contribute? Would I need to build Firefox from scratch to change the printResolution?

You can experiment with this by opening the default viewer (either https://mozilla.github.io/pdf.js/web/viewer.html which always runs the most recent master branch code or a custom checkout), opening the web console and entering PDFViewerApplicationOptions.set('printResolution', 300);. That will set the print resolution to 300 DPI instead of the default 150 DPI. If you then click the print button, you'll notice a difference in print quality, but also in time it takes to render the pages and memory consumption (I just tried this myself to make sure these steps work). The main question is how the print resolution in DPI relates to memory usage/rendering time for various types of PDF files, such as small/medium/large size but also text-only or image-heavy documents. If we know more about how it behaves in various real-life scenarios, we might be able to introduce the setting for Firefox builds too and/or update the default value.

I tried the above method, but I'm getting undefined.
This is with Chrome Canary Version 77.0.3818.0 (Official Build) canary (64-bit)

Yes, running that will give undefined because setting an option has no return value, but if you then print again you'll have increased print output quality.

Thx.
Why isn't this available as a user settable option but only as a programmatically settable one?

This is explained in the comments above, in particular https://github.com/mozilla/pdf.js/issues/2750#issuecomment-496697032. We first want to experiment with it before we make it more easily accessible. Note that just a day ago PR #10879 was merged with should help a bit with the memory usage issue, and now that this is at least programmatically settable, we can more easily experiment with it and include improvements.