Open Bug 1020878 Opened 8 years ago Updated 6 years ago

A blank page is added at the end of some documents when printing


(Firefox :: PDF Viewer, defect, P3)





(Reporter: phorea, Unassigned)



(Keywords: regression, Whiteboard: [pdfjs-c-ff-integration][pdfjs-d-printing])


(3 files)

Reproducible on:
Firefox 30 RC - 20140603140158
 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
latest Aurora -  20140604004003
 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
latest Nightly - 20140604030202
 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

Steps to reproduce:
1. Open a PDF (eg
2. Pay attention to the number of pages
3. Select File - Print Preview and verify the number of pages
4. Print the document

Actual results:
A blank page is added at the end of the document and is printed.
Other pdf samples:

Expected results:
Document is shown in print preview and printed correctly. No extra pages are added to it.

Notes: 1. The issue occurs also Ubuntu 12.10 32-bit and Mac OSX 10.8.5.
2. The issue is a Fx 27 regression:
Last good revision: 4e7d1e2c93a6 (2013-10-18)
First bad revision: e25e62d174ed (2013-10-19)

Possibly regressed by bug 928358 - Update pdf.js to version 0.8.629.
Priority: -- → P3
Whiteboard: [pdfjs-c-ff-integration][pdfjs-d-printing]
In bug 928358:
#3670 Polyfill for mozPrintCallback

Possible regression?
Blocks: 928358
Duplicate of this bug: 1184872
Any news on this?
We also encounter this problem.
When printing one of the samples, a blank page is added.
Also a pdf file we generate (a single page) gets another blank page while printing.
This only happens in pdfjs.

Linux Mint with firefox version: 42.0+linuxmint1+rosa
Windows 7 with firefox version: 42
Duplicate of this bug: 1150433
Duplicate of this bug: 1038735
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160203030249

This bug still persists in Nightly. An additional blank page is printed when using pdf.js.
I managed to retrieve the processed print job file as it is sent to CUPS by pdf.js.
First thing to notice is that it is very large compared to the original or a print job file processed by evince document viewer. I'm really interested why, but i have no idea about it.

Second there's a suspicious text snippet in the bottom after lots of binary glibberish, that reads:

   /Type /Pages
   /Kids [ 13 0 R 20 0 R ]
   /Count 2

Same snippet processed by evince says:

   /Type /Pages
   /Kids [ 10 0 R ]
   /Count 1

...and only one page gets printed instead of two.

I don't speak PDF but maybe someone who knows how the processing happens before print has a clue?
You need to log in before you can comment on or make changes to this bug.