+++ 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: http://www.education.gov.yk.ca/pdf/pdf-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?
This is a huge problem for my clients. https://webconverger.org/printing/ 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.
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.
You need to log in before you can comment on or make changes to this bug.