847049 - Printing from pdf.js rescales/resizes/shrinks output (compared to Adobe Reader printout, both at 100% scaling)

Status: NEW

(Core :: Printing: Output, defect)

Description

[Thomas D. (:thomas8)]

Attachment: Testcase 1: pdf-test.pdf (see URL above)

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

seen on 22.0a1 (2013-03-01)

STR

1 view Testcase 1 (attachment 720284 [details], pdf-test.pdf) with FF pdf.js
2 print it from FF (ensure scaling 100%; FF 93.0 (64-bit): use inbuilt unified print dialog)
3 view same pdf-test.pdf with adobe reader
4 print it from Adobe Reader (ensure scaling original size or 100%)

Actual result

3 printing from pdf.js reduces the size of the output compared to printing from adobe reader (this bug) ~and makes it blurry~ (Bug 811002)
4 printing same pdf from adobe reader produces crisp and assumedly correctly-sized (larger) output.

Expected result

3 FF should print the PDF at its original size if that matches the paper size, without adding margins of any sort. Which might help towards bug 811002, or vice versa.

Comment 1

[Thomas D. (:thomas8)]

Reported against 22.0a1 (2013-03-01) on Windows XP

Comment 2

[Thomas D. (:thomas8)]

Attachment: Printscan 1: Testcase 1 after printing with Adobe Reader (correctly scaled)

Here's a scan of testcase 1 (attachment 720284 [details], see URL) printed with Adobe Reader. I printed a ruler on top. Note:

- crisp print quality
- left margin around 2cm
- length of first text line (Congratulations...) = ~14,5cm~ 15.8 cm
- ~Yukon headline is horizontally adjacent to ruler (vertical offset=0mm)~ Yukon logo vertical offset: 3cm

Comment 3

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #2)
> Created attachment 720292 [details]
> Printscan 1: Tescase 1 after printing with Adobe Reader
> 
> Here's a scan of testcase 1 (attachment 720284 [details], see URL)
> printed with Adobe Reader. I printed a ruler on top. Note:
> 
> - crisp print quality
> - left margin around 2cm
> - length of first text line (Congratulations...) = 14,5cm
Sorry, typo! That line length was measured on FF printout.
On the original print from Adobe Reader, that's:
- length of first text line (Congratulations...) = 15,8cm
> - Yukon headline is horizontally adjacent to ruler (vertical offset=0mm)
- Yukon logo vertical offset: 3cm

Comment 4

[Thomas D. (:thomas8)]

Attachment: Printscan 2: Testcase 1 after printing with FF 22.0a1_2013-03-01 (shrunk and too high on paper)

For comparison, this is the scan of testcase 1 (attachment 720284 [details] [©] [details], see URL) printed with *Firefox* 22.0a1 (2013-03-01). I printed a ruler on top, in same physical position as on attachment 720292 [details].
Firefox printout is shrinked in overall size, but vertically higher on the paper. Note:

- poor print quality
- left margin around 2,5 cm
- length of first text line (Congratulations...) = 14,5cm
- Yukon headline now floats 8mm above the ruler (vertical offset=-8mm)
- Yukon logo vertical offset = 2,3 cm

Comment 5

[Thomas D. (:thomas8)]

Rendering pdfs from FF in my favorite Browser is a nice feature, but it becomes pretty useless without decent printing - after all, pdfs are made for printing.
So essentially, each time I need to print pdfs, I have to go through the hassle of saving, opening & printing the pdf from Adobe Reader. Which constantly makes me wish to go back to having Adobe Reader Plugin in Firefox. Which I'm sure is somewhat against the intention of native PDF support in FF.

https://github.com/mozilla/pdf.js/issues/154 is closed.
https://github.com/mozilla/pdf.js/issues/2101 which reports total garbage print had last activity 6 months ago.

On https://github.com/mozilla/pdf.js/issues/1623, Julian acknoweldges:
> Printing support is very limited (aka. broken). I'm working on make it better
> but it requires to implement some new WebAPIs... See also #154.

But then, #154 is closed :(

Julian, can you provide a status update on pdf.js printing support, and possibly reference some tickets where such work is going on?

Comment 6

[Julian Viereck]

(In reply to Thomas D. from comment #5)
>
> Julian, can you provide a status update on pdf.js printing support, and
> possibly reference some tickets where such work is going on?

I'm not involved closely with this project anymore. If you want to get overview of all the printing problems, please take a look at bug 811002 and all the bugs that it blocks/depends on.

Comment 7

[Deanna Foster]

Merging bug 864871 into this bug.  Adding my sample PDF files showing the issue that now happens when attemtping to print on labels, which require precise output of the PDF.

Comment 8

[Deanna Foster]

Attachment: Original PDF formatted for label printing

This PDF was printed onto labels directly form Mozilla.

Notice on this PDF, how the images on the PDF are slightly "shrunk", resulting in alignment issues.  The stamps do not align with the labels after the first row.

Comment 9

[Deanna Foster]

Attachment: Testcase X2: Original PDF file with stamps for precision printing on sheet of self-adhesive labels

Labels printed from PDF which was saved first

This PDF was downloaded from the application, and then printed from Adobe.  Notice how the stamps line up exactly with the labels.

Comment 10

[Deanna Foster]

Attachment: PrintScan X2: Testcase X2, after printing with FF (showing bogus printing accross labels, due to FF rescaling bug)

This PDF was printed onto labels directly form Mozilla.

Note:  as there was no way to create a PDF from a direct print, I printed this PDF onto the labels, and then scanned the resulting print-out.

Comment 11

[Deanna Foster]

Transferring comment from bug 864871 (which I close as duplicate):
Note:  we have dozens of users in France who upgraded their Firefox versions and experienced the URL printing in the margins causing their stamps to "shrink to fit" the larger margins.  We were hoping with the removal of the URLs that the "shrink" problem would also go away, but apparently it hasn't.

We had out primary testers in France try your latest version as well, so we know it's not a problems specific to a particular browser installation or printer.

They are a very large organization, hence this is having a big impact on not only their users, but their first level support as well.  So, we're really hoping for a solution that doesn't involve the users having to reconfigure their browsers (they are not that technical).

Comment 13

[Scoobidiver (away)]

(In reply to Deanna Foster from comment #11)
> They are a very large organization, hence this is having a big impact on not
> only their users, but their first level support as well.
As a workaround, they can use Firefox ESR (see http://www.mozilla.org/firefox/organizations/faq/) that doesn't have the embedded PDF viewer, hoping this bug is going to be fixed in Firefox 24 or sooner.

Comment 14

[Thomas D. (:thomas8)]

Comment on attachment 746474 [details]
Original PDF formatted for label printing

I'm working with Deanna to sort out a bit of confusion about the various versions of her otherwise excellent testcase. For the meantime, pls ignore comment 8 and comment 9 because the descriptions aren't right.

Both attachment 746474 [details] and attachment 746478 [details] present the unmodified, unprocessed original PDF file which has the correct layout for printing stamps correctly on a sheet of self-adhesive labels.

- when printed with Adobe reader, stamps end up nicely on the labels.
- when printed with Firefox, stamps are printed across labels, due to FF aggressive rescaling (this bug), hence spoiling the whole set.

Comment 15

[Thomas D. (:thomas8)]

Comment on attachment 746478 [details]
Testcase X2: Original PDF file with stamps for precision printing on sheet of self-adhesive labels

So this is the original file with correct layout (open in Adobe reader to ensure correct rendering).

Comment 16

[Thomas D. (:thomas8)]

Comment on attachment 746478 [details]
Testcase X2: Original PDF file with stamps for precision printing on sheet of self-adhesive labels

(In reply to Thomas D. from comment #15)
> Comment on attachment 746478 [details]
> This PDF was printed onto labels directly form Mozilla.
> 
> So this is the original file with correct layout (open in Adobe reader to
> ensure correct rendering).

...now with correct description :)

For details, see comment 14.

Comment 17

[Thomas D. (:thomas8)]

Comment on attachment 746480 [details]
PrintScan X2: Testcase X2, after printing with FF (showing bogus printing accross labels, due to FF rescaling bug)

...so this is the bogus print results after printing from Firefox: Due to incorrect rescaling (this bug), all labels messed up. Quelle malheur!

Comment 18

[Scoobidiver (away)]

(In reply to Thomas D. from comment #17)
> Quelle malheur!
FWIW, it's "Quel malheur !".

Comment 19

[Thomas D. (:thomas8)]

(In reply to Scoobidiver from comment #18)
> (In reply to Thomas D. from comment #17)
> > Quelle malheur!
> FWIW, it's "Quel malheur !".

Sure. My bad, I took the first machine translation without checking... ;)
http://mymemory.translated.net/t/French/German/quelle%20malheur
I've added the correct version there, too.

Grammar aside, it's still a "grand malheur"... :|

Comment 20

[Vestigal]

I'm seeing this on FF 23.0 on Windows 7.

For me, the issue only happens when the PDF is set to "Automatic Zoom." In this case, the PDF displays fine in the browser, but prints at a much smaller size. Zooming to 100% fixes the issue.

For the moment, I'm adding #page=1&zoom=100 to the URLs that our webpage is serving in order to fix the issue, but obviously this is less than ideal.

Comment 21

[David Alan Hjelle]

Just to confirm the page scaling issue in FF27 on Mac. Interestingly, I can manually tell FF not to perform any page scaling, but this is a step most users won't remember to do. The PDFs we generate have the print scaling viewer preference set to none in the PDF, and it'd be great if FF would respect that by default.

I have a sample file I can provide, but it looks like the test cases provided here cover the issue.

Comment 22

[david]

 I can confirm this bug still exists in FF 33.0.2 on Windows 7.

Comment 23

[jrhyne]

(In reply to David Alan Hjelle from comment #21)
> Just to confirm the page scaling issue in FF27 on Mac. Interestingly, I can
> manually tell FF not to perform any page scaling, but this is a step most
> users won't remember to do. The PDFs we generate have the print scaling
> viewer preference set to none in the PDF, and it'd be great if FF would
> respect that by default.
> 
> I have a sample file I can provide, but it looks like the test cases
> provided here cover the issue.

How can you tell Firefox not to perform page scaling? I couldn't find this option.

Comment 24

[les]

I'm having the same problem with the built in PDF viewer (pdf.js). Our company is attempting to standardize FF. We generate a ton of PDFs for print (labels, reports, etc).

With the exception of PDFs with embedded barcode fonts, the PDFs render on screen correctly.  However, printing is horribly broken.

When they do print, they are scaled down to 1/4 size on the printed page. In some cases the content is cut off all together (usually if the page setup orientation doesn't match the document's orientation).  

It doesn't seem to respect the page orientation from the pdf when printing. My guess is that this is related to the scale to fit not working when printing.

No amount of fiddling with the page orientation, scaling, margins, or headers resolves the problem.

I see this on FF 31 and FF 44 on Windows 7 (have not tested other Windows).  I do not have this occur on OS X.

Comment 25

[pranalli]

(In reply to les from comment #24)
> I'm having the same problem with the built in PDF viewer (pdf.js). Our
> company is attempting to standardize FF. We generate a ton of PDFs for print
> (labels, reports, etc).
> 
> With the exception of PDFs with embedded barcode fonts, the PDFs render on
> screen correctly.  However, printing is horribly broken.
> 
> When they do print, they are scaled down to 1/4 size on the printed page. In
> some cases the content is cut off all together (usually if the page setup
> orientation doesn't match the document's orientation).  
> 
> It doesn't seem to respect the page orientation from the pdf when printing.
> My guess is that this is related to the scale to fit not working when
> printing.
> 
> No amount of fiddling with the page orientation, scaling, margins, or
> headers resolves the problem.
> 
> I see this on FF 31 and FF 44 on Windows 7 (have not tested other Windows). 
> I do not have this occur on OS X.

I had the same issue and figured out a solution, hopefully this works for you as well:

Go to the hidden menu option in FireFox by typing "about:config" in the URL bar.  From there, search for "scaling" and look for print scaling options.  In my case, I had users who, for some reason, had this set to 0.8 and 0.25.  Set it to 1 (you may also want to double-check and make sure Shrink to Fit is set to true if applicably), close the tab then close the browser.  I would go back to about:config and make sure the setting stuck.  Once you've done that give it a try.  Worked perfectly for me.

Comment 27

[Marcela (Please NI request to Brindusa Tot)]

Hi Thomas!
I'm trying to reproduce old bugs to see if we can resolve some.
Due to Firefox having change a lot, maybe this problem doesn't happen anymore. I was wondering if you can share it again.
Thanks!

Comment 28

[Thomas D. (:thomas8)]

Attachment: PDF: Scans of testcase1 printouts, scaled 100%, on FF93.0 (64-bit), Win10 vs. Adobe Reader

(In reply to Marcela from comment #27)

Hi Thomas!
I'm trying to reproduce old bugs to see if we can resolve some.

That's great Marcela!

Due to Firefox having change a lot, maybe this problem doesn't happen anymore. I was wondering if you can share it again.
Thanks!

Much better now compared to the original report.
Using testcase1, attachment 720284 [details], Firefox printouts now crispy clear, but still a little bit smaller (2.x %) than direct Printing from Adobe Reader (both scaled to 100%) - would need a better testcase with a measured graphic to find out which one is closer to the original size.

FF 93.0 (64-bit), inbuilt unified Print dialog, Scale: 100%

• width of first line (Congratulations...): 15.4 cm on printout (2.5% smaller than Adobe Reader)
  (FF 22 printed this line 14.5 cm, maybe Fit to page was applied?)
• height of printed area max (top corner of the Y of Yukon to bottom of s in "Please visit..."): 9.2 cm (2.1% smaller than Adobe Reader)

Adobe Reader, print original size or 100%

• width of first line (Congratulations...): 15.8 cm on printout
• height of printed area max (top corner of the Y of Yukon to bottom of s in "Please visit..."): 9.4 cm

Comment 29

[Thomas D. (:thomas8)]

Comment on attachment 9248045 [details]
PDF: Scans of testcase1 printouts, scaled 100%, on FF93.0 (64-bit), Win10 vs. Adobe Reader

You can see the 2.x % difference in size between Firefox vs. Adobe Reader printouts when you open the PDF and flip from page 1 (FF) to page 2 (Adobe reader) and back while looking at the printed area.

Comment 30

[Marco Castelluccio [:marco]]

Given comment 28, this looks more like a Core problem at this point rather than a problem within pdf.js.

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dshin, could you have a look please?

For more information, please visit BugBot documentation.

Comment 32

[David Shin[:dshin]]

Attachment: Output from Nightly 124

Bottom printout is from Firefox, with the folded top printout from Adobe Acrobat Reader DC.
I wonder if we somehow scale down to unprintable margins here...?

Comment 33

[jscher2000]

In Firefox 144, it appears you can print the test case without added margins (same as Acrobat's "Actual" option) by setting Margins to either "Default" or "None". However, users with Margins set to "Custom" will need to switch back and forth manually. Does it make sense to ignore custom margins for PDFs? I'm inclined to think that if someone sets custom margins, they probably prefer to be in control. That said, it would be nice to have a checkbox to "Ignore for PDFs" to ease the switching process.

Comment 34

[gedanke]

I can reproduce a related issue where PDF content is clipped at the edges when printing from Firefox, while the same PDF prints correctly (edge-to-edge) from Acrobat Reader.

Steps to reproduce:

1. Open a full-bleed PDF (content extends to page edges) in Firefox via PDF.js
2. Open the print dialog
3. Print to a physical printer or "Save as PDF"

Actual result:
Content is clipped at the edges. Changing the margin setting from "Default" to "None" has no effect.

Expected result:
Content prints edge-to-edge, as it does when printing the same PDF from Acrobat Reader.

Key observation:
The print preview in Firefox shows the content correctly — nothing is clipped. The clipping only occurs in the actual print output (both to physical printer and "Save as PDF"). This indicates the issue occurs in the pipeline between the print preview and the data sent to the printer.

Root cause (suspected):
PDF.js renders the PDF onto an HTML Canvas for screen display. This canvas is rasterized at screen resolution and passed to the print pipeline as a bitmap. During the canvas rendering step, PDF.js appears to apply a slight internal scaling or padding that clips edge content. Since the output is a raster image rather than vector data, this clipping is baked in and cannot be corrected downstream.

Acrobat Reader does not exhibit this issue because it passes the PDF as vector data directly to the print spooler, preserving the original page geometry.

This is consistent with the core issue in this bug: PDF.js treating PDFs as web content and applying browser-style rendering and margins, rather than passing the original PDF geometry through to the printer.