Bug 18711

Is the problem with printing from evince to a PS file or pdftops? The first uses the cairo output device to generate the PS output. The seconds generates uses the PS Output device.

It would help if you could provide a sample PDF, the incorrect PS output, and the steps to reproduce the problem using only poppler or evince/poppler.

Everything was done on Ubuntu Hardy and Ubuntu Intrepid.

The problem occurs with both evince and pdftops.

Tests were done with the attached PostScript file converted to PDF via

ps2pdf13 testpage-a4.ps

(this used the installed Ghostscript 8.63 for the conversion).

The PDF file was sent to CUPS via

lpr testpage-a4.pdf

On Hardy CUPS immediately converts the file to PostScript using the pdftops filter, on Intrepid the same conversion to PostScript happens in a later filtering step.

The other way to break it is to open the PDF file with evince on Hardy and printing it. In this case evince generates PostScript, using Poppler. CUPS passes this on in PostScript format.

One problem in evaluating the results is that the failure only happens with Brother printers. On the screen or on an HP printer the documents come out correctly.

Wouldn't that be a bug in brother printers?

This still does not narrow it down enough. I'm not going to chase bugs across
multiple packages.

If there is a bug in poppler, and the comment about "only occurs on Brother
printers" leads me to believe the bug is not in poppler, you should be able to:

 - Provide a sample PDF that demonstrates the bug (small and simple is best)
 - Provide the pdftops command line options that you ran
 - Provide the PS output

And if the PS output from poppler renders fine in ghostscript and on HP
printers but breaks on Brother printers, finding out what it is in the PS
output that is causing the problem would help since the only thing I can test
PS on is ghostscript or a LaserJet printer.

The CUPS pdftops filter which is used here (Ubuntu Intrepid) is the one of CUPS 1.4 and this one is a simple wrapper around the /usr/bin/pdftops filter which comes with Poppler. The command line which CUPS uses with the Brother PPD (PostScript Level 3) is

pdftops -level3 -paperw <width> -paperh <height> <input file> -

So the for the attached PDF file (testpage-a4.pdf, evince displays it correctly) for example we would have

pdftops -level3 -paperw 595 -paperh 842 testpage-a4.pdf -

The output file is attached (testpage-a4-pstops.ps).

Version info:

till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ pdftops -v
pdftops version 3.00
Copyright 1996-2004 Glyph & Cog, LLC
till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ dpkg -l | grep libpoppler
...
ii  libpoppler3                                0.8.7-1                                 PDF rendering library
ii  poppler-utils                              0.8.7-1                                 PDF utilitites (based on libpoppler)
till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ 

I have also opened testpage-a4.pdf with evince and printed to a file, set A4 in the Page Setup and chosen PostScript as output format. The result I have attached as testpage-a4-evince.ps.

Created attachment 20625 [details]
Sample PDF file

Created attachment 20626 [details]
PostScript file resulting from conversion with pdftops

Created attachment 20627 [details]
PostScript file resulting from printing to file out of evince

Version info for evince:

till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ dpkg -l | grep evince
ii  evince                                     2.24.1-0ubuntu1                         Document (postscript, pdf) viewer
till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ dpkg -l | grep libcairo
...
ii  libcairo2                                  1.8.0-0ubuntu1                          The Cairo 2D vector graphics library
...
till@till-laptop:~/ubuntu/cups/bzr/debian-trunk$ 

Created attachment 20628 [details]
PPD file of one of the Brother printer for which the problem occurs

Do both testpage-a4-pdftops.ps and testpage-a4-evince.ps have the same offset problem on the Brother printer?

According to the Ubuntu bug report it seems to be the same, but I have asked the posters of the report now.

Both PS files display correctly in ghostscript (using either gv or evince). They also print correctly on my LaserJet. I manually verified the PostScript code that draws the outer box approximately 5 points from the edge of the page. It looks correct in both PS files.

It looks like the problem is in the Brother printer.

The only other thing I can suggest is to create the simplest possible PostScript file that draws a rectangle 5 points from the edge of the page. If that still reproduces the problem you have a broken (or misconfigured) printer.

PostScript files which are not generated from PDFs via Poppler, like the attached testpage-a4-orig.ps print correctly on Brother printers.

Created attachment 20629 [details]
PostScript file which was NOT created by converting a PDF with Poppler

Does the problem occur if the PS files are sent directly the the printer without going through any CUPS filters?

According to the Ubuntu bug report all PostScript files generated by Poppler from PDF files come out shifted, all others not, which would mean for the attached PostScript files that testpage-a4-pdftops.ps and testpage-a4-evince.ps come out shifted and testpage-a4-orig.ps not.

To be sure, I have asked the reporters of the Ubuntu bug now to print all the attached PostScript files without filtering and to tell which ones fail and which ones not.

It might be useful to compare how gs renders the ps files with different
paper sizes and to compare that output with what the printers generate.

If you have a isplay at least 1200 px tall, compare:

gs -dBATCH -g794x1123 -r96 testpage-a4-orig.ps
gs -dBATCH -g816x1056 -r96 testpage-a4-orig.ps

If smaller try these instead:

gs -dBATCH -g595x842 -r72 testpage-a4-orig.ps
gs -dBATCH -g612x792 -r72 testpage-a4-orig.ps

In each pair the first renders the page on a4 sized (virtual) paper,
the second on usletter.

It may be the case that something in the poppler output confuses the
printer into thinking that the src is letter sized, causing it to
misprint to the a4 paper.

Just a supposition.

(Side note:  I'm sure I've read about similar bugs on Brother printers
             before.  Google may point to such discussions and perhaps
             to solutions.  The solution might just be to use PCL when
             printing to those printers, ignoring their PS capability.)

printer-internal settings on which paper size is in which tray are OK. One of the reporters of the Ubuntu bug has printed the three PostScript files attached to this bug without filtering and he gets shifted output only for the file generated by pdftops (testpage-a4-pdftops.ps).

The shift is 1.7 cm to the top, exactly the length difference between A4 and Letter paper.

Created attachment 20656 [details]
PostScript file resulting from conversion with pdftops from the XPDF package

Ubuntu Intrepid contains /usr/bin/pdftops in two packages: poppler-utils and xpdf-utils. By default the one from poppler-utils is installed. For testing I have switched to the one from xpdf-utils now and repeated the conversion of testpage-a4-orig.pdf with this version.

The resulting file (attached testpage-a4-pdftops-xpdf.ps) is only slightly different, but the page size is applied at one more point in the PostScript file:

--- testpage-a4-pdftops.ps	2008-11-27 11:20:22.000000000 +0100
+++ testpage-a4-pdftops-xpdf.ps	2008-11-28 11:42:28.000000000 +0100
@@ -1,4 +1,6 @@
 %!PS-Adobe-3.0
+% Produced by xpdf/pdftops 3.02
+%%Title: testpage-a4.ps
 %%LanguageLevel: 3
 %%DocumentSuppliedResources: (atend)
 %%DocumentMedia: plain 595 842 0 () ()
@@ -9,8 +11,8 @@
 %%PageMedia: plain
 %%EndDefaults
 %%BeginProlog
-%%BeginResource: procset xpdf 3.00 0
-%%Copyright: Copyright 1996-2004 Glyph & Cog, LLC
+%%BeginResource: procset xpdf 3.02 0
+%%Copyright: Copyright 1996-2007 Glyph & Cog, LLC
 /xpdf 75 dict def xpdf begin
 % PDF special state
 /pdfDictSize 15 def
@@ -737,6 +739,8 @@
 false op
 false OP
 {} settransfer
+0 0 595 842 re
+W
 q
 q
 [0.12 0 0 0.12 0 0] cm

Perhaps this version is better in convincing the printer to consider the paper as A4-sized.

pdftops of Poppler is version 3.0, of XPDF is version 3.02 ("pdftops -v").

I suggest to perhaps update Poppler's pdftops to this version.

(In reply to comment #19)
> printer-internal settings on which paper size is in which tray are OK. One of
> the reporters of the Ubuntu bug has printed the three PostScript files attached
> to this bug without filtering and he gets shifted output only for the file
> generated by pdftops (testpage-a4-pdftops.ps).
> 
> The shift is 1.7 cm to the top, exactly the length difference between A4 and
> Letter paper.
> 

Looking at the pdftops file that only thing that stands out is the
setpagedevice code in the pdfSetup procedure. 

Try removing line 719:

  595 842 false pdfSetup

This is setting the page size and the duplex option.

(In reply to comment #20)
> The resulting file (attached testpage-a4-pdftops-xpdf.ps) is only slightly
> different, but the page size is applied at one more point in the PostScript
> file:
[...]
> +0 0 595 842 re
> +W

All this is doing is clipping to a rectangle the size of the page. There is already another clip to the page size a bit further up so I am not sure what the benefit is.

I'd really suggest to consult Brother Linux people if they exist, when i had a similar problem with HP they fixed their drivers in less than a week.

Doing a quick google search revealed an abundance of wrong page size problems with Brother printers. Some pages that provide solutions:

http://bbs.archlinux.org/viewtopic.php?id=55226
https://bugzilla.redhat.com/show_bug.cgi?id=230307
http://solutions.brother.com/linux/sol/printer/linux/printsetlpr.html
http://ubuntuforums.org/showpost.php?p=4763018&postcount=8

You could also try printing in PCL.

Thanks for the links, but all these links point to problems with Brother's proprietary PCL drivers, none has to do with the PostScript PPDs.

Although the discussion about the proceedings might already have clarified, that the bug is NOT in the Brother driver, I have a real life proof for that: the problem occurs on my Xerox Phaser 6130 printer just as well. The errors are not as big as described above: the printout is slightly out of centre and a few millimeters are missing at the borders. (Since Firefox adds its own margins, the full page is printed in spite of the bug.)

Serge van Ginderachter has tested what is described in comment #20 and comment #21. In both cases his Brother printer still showed the problem. He sent the the jobs with the "nc" command to the printer, to avoid any additional filtering.

(In reply to comment #27)
> Serge van Ginderachter has tested what is described in comment #20 and comment
> #21. In both cases his Brother printer still showed the problem. He sent the
> the jobs with the "nc" command to the printer, to avoid any additional
> filtering.
> 

As that removed the only thing that had anything to do setting the page size I can not see anything else in the pdftops output that could cause this problem. The rest is all generic PostScript that does not have anything to do with the page size.

At this point I would recommend contacting Brother. They should be able to either confirm it is a printer bug or tell us what specifically in the pdf2ps output the Brother printers don't like. I can not see anything here that is pointing to a poppler bug.

Your only other option is to trim the PostScript file down until you find the minimal bit of PostScript that triggers the bug. Contacting Brother would be the easier option.

(In reply to comment #26)
> Although the discussion about the proceedings might already have clarified,
> that the bug is NOT in the Brother driver, I have a real life proof for that:
> the problem occurs on my Xerox Phaser 6130 printer just as well. The errors are
> not as big as described above: the printout is slightly out of centre and a few
> millimeters are missing at the borders. (Since Firefox adds its own margins,
> the full page is printed in spite of the bug.)
> 

This bug is about Letter size paper being selected instead of A4 resulting in a 1.7cm shift (exactly the difference between the height of A4 and Letter). If you are seeing a different shift it is not the same issue.

If you think you are having the same problem, try printing the test cases attached to this bug and tell is what the results are. Note that you must bypass all CUPS filtering as described at:

  https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/293832/comments/37

to guarantee that the test file is not modified on its way to the printer.

After some hours of googling, I finally found the culprit: The PageSize policy setting.

See the patch attached in this bug report against IceApe:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469266

This bug report also claims that the PageSize policy is to be blamed:
https://bugs.freedesktop.org/show_bug.cgi?id=17952

But setting it to 1 didn't work for me (Brother HL-5150D). Simply removing the "/Policies ... /PageSize ..." line from the prolog in the testpage-a4-pdftops.ps testcase causes the printout to be correct.

The patch applied to Ubuntu Lucid and proposed in:
https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/293832/comments/107
fixed the very same issue for me with a Brother MFC 7820N.
Any comments on the validity and correctness of the patch so we might get it fixed in poppler if it's really not a driver issue?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/439.

Spam alert ...

Thanks for sharing such a informative blog. It is really helpful for us. Keep sharing such informative blogs again.

Office Com Setup - https://www.office-com-setup.com/