Open Bug 932289 Opened 8 years ago Updated 6 months ago

Low Quality Print Output of PDFs (linux)


(Core :: Graphics, defect)

Not set




(Reporter: milan, Unassigned)


(Blocks 2 open bugs, )


(Whiteboard: [pdfjs-c-feature][pdfjs-d-printing])


(2 files)

+++ This bug was initially created as a clone of Bug #811002 +++

Bug 811002 handles the windows case.  This one is for the Linux scenario.

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:
I still confirm the issue on Firefox 38, Kubuntu 15.04 64bit.

While a PDF viewer works great on Linux, this issue prevents from fully rely on it, as the printed results are blurry and low quality.

Yury, can you please find an appropriate person to work on it?
Flags: needinfo?(ydelendik)
This is a huge problem for my clients.

The problem IIUC is that Mozilla takes PDF, which is basically postscript that printers understand. Then PDFJS rasterizes it. And then converts it back to some postscript which loses all the quality of the original.

The solution in my mind is to somehow bypass PDFJS when feeding the PDF to a print queue.
(In reply to Kai Hendry from comment #2)
> ...
> The solution in my mind is to somehow bypass PDFJS when feeding the PDF to a
> print queue.

That makes all kinds of sense, though I imagine there is some complication as to why it isn't done that way right now.  My usual workaround is to at that point download the PDF and use the "native" printing...
(In reply to Kai Hendry from comment #2)
> The solution in my mind is to somehow bypass PDFJS when feeding the PDF to a
> print queue.

Yes, we are looking for solution and a contributor who wants to take such task: to be able to create cross-platform level API to send/print selected PDF pages as is without using a canvas or svg. mozPrintCallback closest solution that we could find to fill a gap of flexible printing capabilities in the web platform. 

(In reply to Boaz Dodin from comment #1)
> Yury, can you please find an appropriate person to work on it?

I personally was unable to find such person.
Flags: needinfo?(ydelendik)
As a temporary fix, I changed the PRINT_OUTPUT_SCALE to 6 in the "beforePrint" function(around line 4017 in viewer.js).
The print output quality is fairly ok now. 
I tried with larger numbers but the viewer crashed, so i settled with 6 for now.

Hope it helps until this bug is fixed.
Attached image IMG_1206.JPG
It seems like FF 50 is still having problems. Here's the same PDF printed using evince (left) and using Firefox 50 (right) on the same printer and the same paper. The jagged letters on the right are not an artefact from the camera. That's really how it looks like.

This is still an issue with Firefox 76.0.1, and is particularly annoying for my use case (printing server-generated barcode labels on a Brother QL-500 thermal label printer).

I'd like to work on this but as a novice contributor I would need some significant support. Totally aware that that in itself would be a time commitment for someone with more experience working on Firefox/pdf.js. If someone could put an hour into teaching me, in particular how I should approach building a test case for this and where that test case would go, I'd appreciate it. It seems like Bug 1661294 might be related if that information is needed to send the pdf directly to the print service?

I've started looking into the flow of data in printing, but stuck right now on getting gdb to actually break on the printing functions.

I've put a 50$ BOUNTY on this bug, because this honestly really needs to get solved. Anybody who's trying out Firefox and experiences this printing problem is just going to have yet another reason to switch away from Firefox.
I have the same issue where if I print it trough Okular or any other pdf printing program it's fine, but when I print the pdf in firefox, the end result is a blurry print

You need to log in before you can comment on or make changes to this bug.