printer prints page at wrong position, page cut

[somebody74]

After updating to intrepid, my Brother DCP-7025 printed every page about 2 cm above the usual position. This leads to pages cut as if printing with wrong paper configuration though A4 paper is set everywhere (Cups settings, program settings). For example when printing a test page with the printer configuration tool I cannot see the upper part of the Ubuntu logo.

I have used both a hardy and an intrepid live cd to test and found out that the problem only occurs using intrepid, so I think it's a problem with the intrepid driver packages.

However I found out, that in the printer configuration tool a wrong driver "DCP-7025 BR-Script" is loaded. The correct (and working!) driver is "DCP-7025 for CUPS". So to manually solve the problem simply choose the correct driver in the tool.

I think that during the installation process of the package "brother-cups-wrapper-laser" the correct driver is not set to be used as default driver and the system continues to use the wrong driver instead.

[Saivann Carignan (oxmosys)]

Thanks for your bug report! To be sure that I understand correctly your bug description : this problem happens only with DCP-7025 BR-Script printer driver and not "DCP-7025 for CUPS", is that right?

[somebody74 (steffenwittkamp)]

Yes, that's correct.

[Saivann Carignan (oxmosys)]

Thanks for your answer. According to the fact that the margin problem can only be reproduced with the driver from openprinting-ppds, I change the package to foomatic-db . Unfortunately, concerning the the fact that the driver from Brother is not automatically selected by cups, it is normal in the present that cups prefer opensource drivers in the openprinting database instead of the ones we manually add. The brother-* packages only add new drivers that cups is free to use. This might change in the future if something is done so brother-* packages get automatically installed (bug 234822).

[Till Kamppeter (till-kamppeter)]

The problem is that probably the pstopdf filter does not determine the margins correctly.

Can you all replace your /usr/lib/cups/filter/pstopdf by the attached file? Please do not forget to make it executable

sudo chmod 755 /usr/lib/cups/filter/pstopdf

Can you print correctly now?

[Till Kamppeter (till-kamppeter)]

I have fixed another bug. Please test with this new version of pstopdf, not with the one of the previous comment.

[somebody74 (steffenwittkamp)]

Switching back to the BR-Script driver and using the new pstopdf filter did not change anything for me.

[Till Kamppeter (till-kamppeter)]

Does the wrong positioning of the page always occur or only for certain applications?

Does it work correctly if you print a PDF file directly via

lpr -P <queue> <PDF file>

This would suggest that the problem is caused by pstopdf.

[Till Kamppeter (till-kamppeter)]

If I set up a queue which points into a file and uses the BR-Script PPD for the DCP-7025 (/usr/share/ppd/openprinting/Brother/BR7025_2_GPL.ppd.gz) and display the output with Ghostscript I get correct results. So it seems that the shift happens inside the printer. For further investigating this I would need a PostScript output file from Hardy and one from Intrepid, to see what the filters do differently.

[Till Kamppeter (till-kamppeter)]

Are you sure that you have selected the correct paper size (A4/Letter)?

[somebody74 (steffenwittkamp)]

Yes, correct paper size was automatically selectet in Cups and every application I tested. The problem also occured in all these applications (Open Office, Evince, Acrobat Reader, Cups test page printing, Ubuntu test page printing).

You wrote that a Postscript output file from Hardy and Intrepid could help you. If you tell me how to generate such a file, I will do that with both Hardy and Intrepid Live CDs.

[Till Kamppeter (till-kamppeter)]

Can you also try to replace your /usr/lib/cups/filter/pstopdf by this one:

http://www.openprinting.org/download/printing/pdf-printing/pstopdf

Do not forget to make the filter world-executable.

Does printing work correctly for you now?

[Martin Pitt (pitti)]

A new cups package just got uploaded into intrepid-proposed and should be available for testing in some hours. Can you please test this and report back whether it fixes your problem?

cups (1.3.9-2ubuntu2) intrepid-proposed; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/cpdftocps: The cpdftocps filter did case-sensitive
    checking for CUPS options to keep them away from the pstops filter. CUPS
    treats such options case-insensitive, so in some cases CUPS options got
    applied twice (LP: #299707).
  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx: Fix handling of
    CMYK color space. Patch taken from upstream:
    http://svn.sourceforge.jp/view/pdftoraster/trunk/src/pdftoraster.cc?root=opfc&rev=850&r1=848&r2=850
    (LP: #294671)
  * debian/filters/pstopdf: Do not supply the margins from the PPD to the
    ps2pdf process, as this breaks full-bleed printing and is also disturbs
    the printing if PPDs have too conservative margin definitions. (LP: #282186)

  [ Martin Pitt ]
  * rootbackends-worldreadable.dpatch: Apply the same relaxed permission check
    to cups-deviced, so that backends installed as 0744 don't disappear from
    printer detecttion. This unbreaks the ipp/http and lpd detection.
    (LP: #275407, Debian #503644)
  * debian/rules: Install the serial backend with 0744 permissions to make it
    run as root, since /dev/ttyS* are root:dialout and thus not accessible as
    user "lp". Thanks to Chanoch (Ken) Bloom. (part of #506181, LP: #154277)
  * debian/control: Update Vcs-* for intrepid branch.

 -- Martin Pitt <email address hidden> Fri, 21 Nov 2008 11:22:24 +0100

[Till Kamppeter (till-kamppeter)]

Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed.

[Till Kamppeter (till-kamppeter)]

somebody74, at first test the package from -proposed, to see whether this perhpas already fixes the problem.

If not, do the following test:

sudo -s
mv /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftopdf.orig
cat > /usr/lib/cups/filter/pdftopdf << EOF
#!/bin/sh
cat \$6
EOF
chmod 755 /usr/lib/cups/filter/pdftopdf
exit

Note that all commands between "sudo -s" and "exit" are executed as root (you have a prompt ending with "#").

This short-circuits the pdftopdf filter. So we can see whether the pdftopdf filter causes the shift.

Undo this change via

sudo mv /usr/lib/cups/filter/pdftopdf.orig /usr/lib/cups/filter/pdftopdf

If the pdftopdf short-circuit does not help, extract the PostScript output in both Hardy and Intrepid, to do so, replace /usr/lib/cups/filter/cpdftocps by the attached file. Save a copy of the original file and make sure you make the new file world-executable.

After printing you will have a file /tmp/printout which contains the PostScript file. Attach the two output files.

[somebody74 (steffenwittkamp)]

Hello again,

All the following tests were done with live-cd systems:

First I tested the new cups package (1.3.9-2ubuntu3) from proposed-sources using an intrepid live-cd, but that did not change anything.

Then I tested the short-circuit for the pdftopdf filter using the commands Till wrote. Again that did not solve the problem.

After that I extracted the PostScript output in intrepid by the method Till described (replacing cpdftocps). I have attached the output. I could not do the same thing using hardy-live-system because a cpdftocps file did not exist there. If you need this output file, please tell me how to generate it using hardy.

Thanks for your efforts

[Till Kamppeter (till-kamppeter)]

On Hardy clone your print queue with the "Copy" function in system-config-printer. Give the name "x" to the copy. Then run the commands

cupsctl FileDevice=yes
cupsctl LogLevel=debug
lpadmin -p x -v file:/tmp/printout

Then print a job on x and wait for it to finish. Then attach /tmp/printout to this bug report.

[somebody74 (steffenwittkamp)]

Okay, here is the printout that hardy generates

[Till Kamppeter (till-kamppeter)]

Can you print PDF files with Hardy, by sending them directly to CUPS with a command like

lpr -P <printer> <PDF file>

Can you try this also with PDFs generated by Ghostscript, especially with the PDF resulting from

ps2pdf13 /usr/share/system-config-printer/testpage-a4.ps

and

ps2pdf13 -dAutoRotatePages=/None -dAutoFilterColorImages=false -dNOPLATFONTS -dPARANOIDSAFER -sstdout=%stderr -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/printer -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -r1200 /usr/share/system-config-printer/testpage-a4.ps

If of these two one prints correctly and the other one not, try also parts of all these options, to perhaps find the one which breaks it.

[Serge van Ginderachter (svg)]

marked as duplicate of my #293690 see report for more details

Just tested the -proposed update, does not fix the problem.
I'm experiencing this problem with Brother MFC 7420N
Not alle applications are affected, Firefox being the noteable exception which does print stuff ok.

I'm not sure which extra tests I should provide now, to help out, let me know if you need extra info/tests.

[Till Kamppeter (till-kamppeter)]

Serge van Ginderachter, if you have a Hardy box handy (or a live CD of Hardy) then try the test which I described in my previous comment.

[somebody74 (steffenwittkamp)]

I tested the commands with Hardy-Live CD and

lpr -P <printer> <PDF file>

with the PDF generated by

ps2pdf13 /usr/share/system-config-printer/testpage-a4.ps

led to the same wrong positioning I experienced only in Intrepid before! Hope this result helps in finding the problem.

Concerning Serge van Ginderachter's comments I have to add, that Firefox does not print correct for me under Intrepid, though it does not cut the page at the top. Instead it prints the complete page but shrinks it to the upper 75% of the paper.

[Serge van Ginderachter (svg)]

OK. I took some openoffice document and converted it to PDF and used that for those tests, in the following order

On hardy:
- printing lpr -P <printer> <PDF file> gave an erroneous document complaining on the PDF command code (ERROR NAME; typecheck COMMAND image OPERAND STACK; )
- created test page with ps2pdf13 and printed with lpr -P <printer> <PDF file> --> problem surfaces, page is moved upwarts as in Intrepid
- created test page with ps2pdf13 + extra options and printed with lpr -P <printer> <PDF file> --> problem surfaces, page is moved upwarts as in Intrepid
- printed my OOo generated test page with evince --> problem shows up here also!
- printed y OOo generated test page with acroread --> prints is OK
As I'm using acroread more often than evince, it is possible I never noticed this was a problem, but I have a feeliong I did not allways have this problem with evince.

Please also note this is actually a problem I already had pre-hardy, which got fixed in Hardy, and regressed now in Intrepid.

HTH

[Till Kamppeter (till-kamppeter)]

Thank you for all the testing. It looks like that Poppler has a bug on PDF-to-PostScript conversion.

Sending a Ghostscript-generated PDF (ps2pdf13) to CUPS produces the problem, as CUPS converts the PDF to PostScript with its pdftops filter, which is Poppler-based. Also the OOo generated PDF fails when converted to PS via Poppler (evince is Poppler-based). The problem does not occur when not using Poppler (acroread).

In Intrepid, with the new PDF-based printing workflow, all jobs get converted to PDF (if not directly sent in PDF format by the app) to pass them through the pdftopdf filter to do the page management (N-up, reverse order, selected pages, manual duplex, ...). After that they have to get converted into the native language of the printer. For PostScript printers this job is done by the cpdftocps CUPS filter. This filter calls CUPS' pdftops filter, so the conversion is done with Poppler.

I will post a GhostScript based replacement for CUPS' pdftops filter for testing soon.

[Till Kamppeter (till-kamppeter)]

Replace your /usr/lib/cups/filter/pdftops file by the attached one and do not forget to make it world-executable. Then print again. Do the pages come out correctly now?

[somebody74 (steffenwittkamp)]

No, printing doesn't work at all with this replacement:

Error message:

P2POutputStream:write error

I attached the more detailed error message I got.

[Till Kamppeter (till-kamppeter)]

I am attaching another version. please try it.

[Till Kamppeter (till-kamppeter)]

See

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

especially comments

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

The users who complain about this problem have PostScript printers maninly from Brother (on my HP printers the problem does not occur). Whenever PDF gets converted to PostScript in the printing filter chain, for example when printing from the Poppler-based Evince or when sending a PDF file directly to CUPS ("lpr <PDF file>") which triggers the Poppler-based pdftops filter, on Brother's PostScript printers (perhaps also other brands) the content of the page is moved 2-3 cm to the top, being cut at the top and leaving space on the page at the bottom.

[Adrian Johnson (ajohnson-redneon)]

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.

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

Reported Poppler problem upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=18711

But please still do the test with my second Ghostscript-based pdftops filter.

[Albert Astals Cid (aacid)]

Wouldn't that be a bug in brother printers?

[Adrian Johnson (ajohnson-redneon)]

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.

[somebody74 (steffenwittkamp)]

Printing still does not work with the new version of pdftops. Same error message.

[Till Kamppeter (till-kamppeter)]

somebody74, can please activate debug logging with

cupsctl LogLevel=debug

print a job and after the job got completely processed (job disappears or goes into "Stopped" state) post your /var/log/cups/error_log file here?

Can you also look for messages containing "audit" in /var/log/syslog and post them here? Try also to switch off AppArmor protection with

sudo aa-complain cupsd

After testing reactivate AppArmor with

sudo aa-enforce cupsd

[Till Kamppeter (till-kamppeter)]

somebody74, are you sure that you have really replaced /usr/lib/cups/filter/pdftops by my second file?

[Serge van Ginderachter (svg)]

I just tested both scripts, and both solve the problem for me.
I kept the second 'in production' for now. Let me know if you need more info.

Thanks for your support!

[Till Kamppeter (till-kamppeter)]

Serge, great to hear that it work for you. somebody74 probably hit another bug. We eill have to see his error_log.

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20625)
Sample PDF file

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20626)
PostScript file resulting from conversion with pdftops

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20627)
PostScript file resulting from printing to file out of evince

[Till Kamppeter (till-kamppeter)]

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$

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20628)
PPD file of one of the Brother printer for which the problem occurs

[Adrian Johnson (ajohnson-redneon)]

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

[Till Kamppeter (till-kamppeter)]

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

[Adrian Johnson (ajohnson-redneon)]

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.

[Till Kamppeter (till-kamppeter)]

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

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20629)
PostScript file which was NOT created by converting a PDF with Poppler

[Adrian Johnson (ajohnson-redneon)]

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

[Till Kamppeter (till-kamppeter)]

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.

[James H. Cloos Jr. (cloos-jhcloos)]

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.)

[Till Kamppeter (till-kamppeter)]

somebody74, Serge, to exclude any problems caused by Brother's PPD file can you set up a "Generic PostScript printer"? and try to print through this queue using the original pdftops filter?

[Till Kamppeter (till-kamppeter)]

somebody74, Serge, if you are on Hardy, is the shift of the output the same independent whether you print a PDF with evince or via "lpr <PDF file>"?

[Till Kamppeter (till-kamppeter)]

somebody74, Serge, can you print all the PostScript files which are attached to the upstream bug report

https://bugs.freedesktop.org/show_bug.cgi?id=18711

without any filtering to your printer, using one of the following commands:

lpr -P <printer> -o raw <file>

nc -w1 <printer's IP> 9100 < <file>

sudo -s
cat <file> > /dev/usblp0
exit

It does not matter whether you do this from Hardy or from Intrepid. It also does not matter which driver you have set up for your print queue.

Please telll which files come out shifted and which ones OK.

[Till Kamppeter (till-kamppeter)]

I have done some tests what happens when the printer-internal configuration is wrong. On my HP LaserJet P3005 A4 paper is loaded into the main input tray (Tray 2). In the front panel manues of the printer I have entered that Tray 2 contains Letter paper. Then I have printed the PostScript files attached to the Poppler bug report unfiltered, using the command line

nc -w1 <printer's IP> 9100 < <file>

They came all out leaving the last two centimeters of the page blank. One file was shifted to the top and cut, another file was scaled down to fit into the remaining space of the page.

So please check the front panel menus of your printer, especially the paper sizes assigned to the trays. They must be set to what is actually loaded into the trays.

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=20656)
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.

[Adrian Johnson (ajohnson-redneon)]

(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.

[Adrian Johnson (ajohnson-redneon)]

(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.

[Serge van Ginderachter (svg)]

- generic printer -> problem remains
- hardy: print evince or lpr: problem remains the same, same shift
- test pages
   * evince: print ok
   * original: print ok (but low quality)
   * pdftops: print shifted (1.7 cm)
- front panel menu on printer: no paper settings available, so n/a; via webinterface: setting is on A4 which is OK

[Till Kamppeter (till-kamppeter)]

Intrepid (and probably Hardy, too) 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 (testpage-a4-pdftops-xpdf.ps attached to upstream bug report) 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").

Serge, somebody74, can you print the last attachment of the upstream bug report (testpage-a4-pdftops-xpdf.ps) without filtering to see whether this helps?

If it works, you can make your Intrepid environment working by switching to the XPDF version. Make sure that the Universe package source is activated and do

sudo apt-get install xpdf-utils

In the case that this breaks something else youi can always undo it by

sudo apt-get install poppler-utils

[Till Kamppeter (till-kamppeter)]

Serge, somebody74, can you also try what Adrian Johnson is suggesting in comment #21 of the upstream bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=18711#c21

[Albert Astals Cid (aacid)]

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.

[Adrian Johnson (ajohnson-redneon)]

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.

[Till Kamppeter (till-kamppeter)]

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.

[Menno (m-tjoelker)]

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 (svg)]

Hi Till,

Sorry I didn't respond earlier, been busy.

$ nc -w1 procyon 9100 < testpage-a4-pdftops-xpdf.ps
--> does NOT solve the problem, so didn't test further with xpdf-utils

then removed line 719:
  595 842 false pdfSetup
--> problem still remains!

HTH,

Serge

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

This means that any PDF-to-PostScript conversion from pdftops, independent whether based on Poppler or XPDF is not able to convince a Brother PostScript printer to switch to A4 paper size and that the pdfSetup function in the PostScript output is not the culprit.

[Adrian Johnson (ajohnson-redneon)]

(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.

[Adrian Johnson (ajohnson-redneon)]

(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.

[reindeer (reindeer)]

Hi,

I also experience a similar problems with print outs on a Brother HL-5051D, using Intrepid Ibex and also before using Hardy Heron. I am note sure, but believe that with Gutsy Gibbon, there were no problems.

I am using the attached /etc/cups/ppd/HL-5150D.ppd

[Sam Liddicott (sam-liddicott)]

I also has the problem, using a Brother MFC-260C but updating just now with intrepid-proposed has fixed it.

Thanks.

[Michael Gefen (gefenm11)]

i have a similar issue with Brother HL-2030
the lower left corner stays always at 0x0

i tested with the latest cups: 1.3.9-2ubuntu7
the issue was till there.

when i downgraded to: 1.3.9-2ubuntu6.1
the issue was till there.

when i downgraded to: 1.3.9-2 (the version that come with the install CD)
the issue was resolved.

i'm using the HPIJS driver.

[Michael Gefen (gefenm11)]

future testing showed that downgrading fixed the margins issue with other drivers (such as those provided with the brother-cups-wrapper-laser)

[Eric Donkersloot (ericd)]

Seems I have the same issue, using Jaunty and a HP Photosmart C4380:

ii cups 1.3.9-14ubuntu2
ii hpijs 2.8.12-3ubuntu2
ii hplip 2.8.12-3ubuntu2

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu jaunty (development branch)"

[Sam Liddicott (sam-liddicott)]

Seems I have the same problem with Brother MFC-260C on Jaunty

[Michael Gefen (gefenm11)]

i tested this issue against the latest purposed (in 8.10) : cups-1.3.9-2ubuntu8

the page is still printed off margins.

using the est page from cups (the one with rulers) give the following information it Imageable area:

using cups 1.3.9-2

page size: 7.76x11.3in
                 192.2x286.9mm
lower-left: 0.25x0.2in
                 6.4x5.1mm
upper-right: 8.01x11.5in
                 203.5x292.0mm
resolution: 600x600dpi
                 23562x23562dpm

using cups 1.3.9-2ubuntu8

page size: 2.26x11.7in
                 209.9x297.1mm
lower-left: 0.0x0.0in
                 0x0mm
upper-right: 2.26x11.7in
                 209.9x297.1mm
resolution: 600x600dpi
                 23562x23562dpm

in both tests, the same PPD was used (Brother HL-2060 Foomatic/hpijs (recommended)) with HL-2030 printer

it seems that the newer cups ignore the margin settings in the ppd.
a photo of both printouts attached.

[Achim (ach1m)]

I have an Canon-Pixma-IP5200R and I am also affected by that problem.
I have tested it with the Gutenprint driver and the proprietary Turboprint driver for testing purpose. http://www.turboprint.info/

The problem exists with both drivers. So my conclusion is that the problem is driver independent.
I hope that Information is somehow helpful.

[Achim (ach1m)]

Today I tested the ubuntu Jaunty beta from LiveUSB and the problem seems to be gone.
The printout was correctly positioned.

I have no idea what was wrong, but everything seems to work like it should.

[Sam Liddicott (sam-liddicott)]

I de-installed:
sudo dpkg -r brother-cups-wrapper-extra brother-lpr-drivers-extra

and installed from the brother website
sudo dpkg -i Desktop/mfc260ccupswrapper-1.0.1-1.i386.deb Desktop/mfc260clpr-1.0.1-1.i386.deb

and it all works fine for me.

[Sam Liddicott (sam-liddicott)]

I take that back.

The official brother debs cause the test-print page to print properly,
printing from firefox seems to come out fine

but printing from gedit still cuts off the first 2 text lines, although the left columns are all there.

The printer job options margins were all set to 0 points. I set them all to 24pt which moved the text about 1.5 em's to the right, but about six lines down suddenly making room for the gedit page header as well as the missing 2 lines.

Most weird, maybe "0" as a margin value has a magic meaning?

[Sam Liddicott (sam-liddicott)]

Now I put the margins back to 0 and I still get the gedit header.

Consider these the ravings of a loony unless someone else reproduces it; I'm back to saying that the brother's own packages do work and the ubuntu brother ones don't

[Arnaud Atoch (arnaud-atoch)]

Printing with an Epson R320 with Ubuntu R320 on Intel x32 arch, whatever the software used to print : Open Office or Document Viewer , top margin is almost null and does not react to printer properties. Left and rigth margins are ok.

[Arnaud Atoch (arnaud-atoch)]

Printing on the same system with the old xpdf application does not show the issue : that is top margin is exactly what is defined in the document.

[Michael Gefen (gefenm11)]

after updating to jaunty, the issue remained.

on my previous tests ( https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/293832/comments/50 ) i only downgraded the cups package, leaving other related packages up to date. thus i conclude that it is a regression in cups.

[Till Kamppeter (till-kamppeter)]

Please try the update for Jaunty following the instructions in bug #357732.

[Michael Gefen (gefenm11)]

sending a pdf to printer using acrobat:
this is the command generated by acroread:

lpr -P HL-2030-series -o PrintoutMode=Normal -o InputSlot=Default -o PageSize=A4 -o PageRegion=A4 -o Duplex=None -o Quality=FromPrintoutMode

resulted with a printout having correct margins

[Michael Gefen (gefenm11)]

the solution that appear there did not help me

[Pavel Rojtberg (rojtberg)]

you probably need to execute:
brprintconf_<your_model> -pt A4 # brprintconf_dcp135c in my case

description:
http://solutions.brother.com/linux/sol/printer/linux/printsetlpr.html

[Till Kamppeter (till-kamppeter)]

Can anyone check on the current Karmic whether this is still an issue?

[Kasper Peeters (kasper-peeters)]

I am reproducing this bug on jaunty, with cups-1.3.9-17ubuntu3.2. Downgrading to cups-1.3.9-17ubuntu3.1 resolves the problem. It does not seem to be brother-only, as the same problem occurred on a Samsung ML-1710 (with the Splix driver). Cups has paper size set to A4 and /etc/papersize contains "A4" as well.

[Till Kamppeter (till-kamppeter)]

Can you call system-config-printer via "System" -> "Administration" -> "Printing", then right-click your printer's icon, choose "Properties" and in the window which pops up then choose "Job Options". There set the "Fit to Page" option. Does this solve the problem?

Can you also attach the document with which you have the problem and tell how you printed it?

[Kasper Peeters (kasper-peeters)]

Assuming you mean 'Scale to Fit', turning that one on does not resolve the problem.

The problem occurs e.g. when printing PDF files from evince. Will try a few more things before sending test documents.

[Vince Callaway (vince)]

I came across this problem a few days ago. I have an application that generates PDF's and was able to do quite a bit of testing.

First off this is not an Ubuntu specific bug. So far SuSe, Centos and Ubuntu systems tested all have it. So it is a cups specific bug.

The problem appears to be with any printer that does full bleed printing. All of the inkjet photo printers and color lasers I tested failed. Those were Brother MFC-5840CN, MFC-465CN and Samsung CLP315W. The B&W Lasers that I tested on were HP 1200, HP 1320, Brother MFC-7345N and Brother MFC-8670DN. All of those printed fine.

All the pdf files I generated where opened with Acrobat or evince and then printed came out ok. On my system those use gnome-print libraries which I believe convert everything to postscript. Not sure so someone smarter than me needs to add to that.

[Henning Eggers (henninge)]

I am having the same regression on a Brother MFC-7820N on a current Jaunty.

[ferrouswheel (joel-pitt)]

I was also having this problem with a brother MFC885CW on a current Jaunty.

sudo brprintconf_mfc885cw -pt A4

seems to have fixed it.

[Nicolas Piguet (npiguet)]

I was also having the same problem with an MFC-260C on Jaunty. Fortunately I stumbled on this bug report.

sudo brprintconf_mfc260c -pt A4

also did it for me. I can finally see the top 2 or 3 cm of the PDF's I print.

[Serge van Ginderachter (svg)]

OK, this bug regressed for me after upgrading to Karmic.
I still had the script (pdftops) mentioned earlier in this bug report, using dpkg-divert
I removed the divert and restored the pdftops.real, but no difference.

I checked the tools on http://solutions.brother.com/linux/en_us/download_prn.html as to find the brprintconf util, but those packages are all i386 and I'm running amd64...

Am I missing yet another solution?

On a side note, I fail to understand the Real Underlying Problem - getting a little annoyed about a bug that comes, goes and regresses over the last 3 releases - what can I do to get this sorted out definitively?

[Serge van Ginderachter (svg)]

OK, installing the

  brother-cups-wrapper-laser package

and reconfiguring my printer solved this for now. (I hav a Brother MFC-7420N)

[Marcin Gryszko (marcin-gryszko)]

Serge, you have to follow Brother instructions for Ubuntu 64 bits. You have to install C/C++ libs for 32 bits and then install everything with dkpg --force-all option.

[Mike (0x656b694d)]

Xerox Phaser 3122 here with the same problem.
I tried to print from OpenOffice Writer, and the test page. Got cut top of the pages.
9.10, 64 bit.
Xerox Phaser 3122, SpliX V. 2.0.0

[Sam Liddicott (sam-liddicott)]

This has just started happening for me again, today, the top of all pages on my brother MFC260C is cut off.

[B-steinbrink (b-steinbrink)]

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.

[Till Kamppeter (till-kamppeter)]

I can suggest a possible fix for this problem. See comment #30 of Poppler upstream bug #18711:

http://bugs.freedesktop.org/show_bug.cgi?id=18711#c30

I patched Poppler to follow the suggestion there and at least I cannot see a regression: My HP printers still print and Ghostscript displays the files correctly on the screen.

A debdiff for Lucid's Poppler is attached. Please upload the new Poppler package (we can remove the ptach later if it shows regressions).

To the reporters of the bug: Please try as soon as the new Poppler gets available (use a Lucid live CD) and report whether it fixes your problems.

[Till Kamppeter (till-kamppeter)]

Marked the tasks on CUPS and on the Brother non-PostScript driver packages invalid as we have localized the problem in Poppler now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package poppler - 0.12.2-2.1ubuntu3

---------------
poppler (0.12.2-2.1ubuntu3) lucid; urgency=low

  * debian/patches/10_fix-a4-page-shift-on-brother-ps-printers.patch:
    Fixed page shifts when printing on A4 paper with Brother PostScript
    printers, by applying the changes suggested in Poppler upstream bug
    18711, comment #30 (LP: #293832).
 -- Till Kamppeter <email address hidden> Thu, 17 Dec 2009 23:39:23 +0100

[Kasper Peeters (kasper-peeters)]

This still is a problem on Karmic. A default installation, with a
Brother DCP7025 connected, activates the "Brother DCP7025"
driver. That one prints with the notorious offset. Installing
"brother-cups-wrapper-laser" by hand and then selecting "Brother
DCP7025 for CUPS" resolves the issue.

Let me know if there's anything I can do to help debug this.

[Till Kamppeter (till-kamppeter)]

Attached is a debdiff to fix this problem in Karmic which I propose as an SRU. It is a one-line patch which did not cause any regression in Lucid, so I think it will be very helpful for Karmic users. This bug affects 8 persons and has one duplicate, so there are several users with a PostScript printer from Brother.

[Till Kamppeter (till-kamppeter)]

Kasper Peeters, the already released fix is only for Lucid, the Ubuntu version under development, to be released end of April. As the patch is small I have now proposed an update for Karmic. There will be a call for testing it soon. Please test it then.

[Martin Pitt (pitti)]

Accepted poppler into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Olivier Berten (olivier-berten)]

If it's been fixed on 2010-03-16, is it normal that a clean Lucid install on 2010-03-26 still shows the problem?

[Olivier Berten (olivier-berten)]

That install being from a Beta1 CD, followed by on-line update from all possible official repositories, including 'proposed'.

[Raid996 (khyaninlot)]

I have the same problem, mine is a Brother MFC-5460CN.
I've had the problem since transitioning with a clean install form 8.10 to 9.04, the bug persisted in 9.10 (clean install).
I've been using Lucid since Alpha2 and have had the same problem, in the past week however another problem came up: other than the format problem now if I tell my printer to print in low resolution and grayscale it will print in color and full resolution.

I have now a fully updated Lucid install, and the problem is still there.

Renato Campus

[Andrea Ratto (andrearatto)]

Confirming with a Brother MFC-5460CN on Lucid. Please re-open this.

[Till Kamppeter (till-kamppeter)]

Note: This bug report is only about Brother's PostScript (BR-Script) printers used in PostScript (BR-Script) mode. If you are using Brother's LPD drivers and CUPS wrappers your problem is another bug, most probably bug 550764.

[Martin Pitt (pitti)]

Anyone who can test the karmic-proposed package? I'll remove it soon if there is no testing feedback. Thank you!

[Martin Pitt (pitti)]

Removed from karmic-proposed due to lack of testing for half a year.

[Impulze (impulze)]

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?

[Ludovic GIAMBIASI (ludovic-giambiasi)]

Hi,

I use the 11.04 ubuntu version and I have this same bug.

I find a solution very simple.

my pdf are opened with Okular.

I have just to
cocher la case "Forcer la rastérisation (conversion en image)"
(sorry it's in french, I don't know in english)
in the options settings after file/print... in "options PDF"

and it's work !

[Laurent Dinclaux (dreadlox)]

Still happens in 12.04, there is a hudge top margin.

[Till Kamppeter (till-kamppeter)]

Laurent, can you tell us which printer you have, which driver you are using, and follow the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

[Fiorenzo De Santis (fiod3s)]

I'm experiencing a problem like that with my Brother HL-2270DW in Ubuntu 12.10. Top and left margins are affected. A workaround is to print to a .ps file then print from that file. However a better solution is to use a Generic PCL6 Driver.

This problem is also discussed on http://ubuntuforums.org/showthread.php?p=12381534

[Gitlab-migration (gitlab-migration)]

-- 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.

[Orzel (orzel)]

Spam alert ...

[unfa (unfa00)]

I have the same problem with a HP DeskJet 3700 printer.

I've tried Linux Mint 18.3 and Manjaro 18.0.2.

I had no success, until I tried one thing:

In LibreOffice 6.1 I forced printer to use PostScript instead of PDF output - and the print was finally good!

Now my question is - how can I fore this system-wide? I haven't seen such an option in any printer configuration tools or on the CUPS web UI.

The problem is clearly with the PDF output. PostScript seems to work fine.

[unfa (unfa00)]

If I select "Force Ratestization" in "PDF Options" in Okular, the print is fine.

Unfortunately this setting is reset with every print.

Now if I could force this system-wide - it'd fix the problem.

[unfa (unfa00)]

Oh wait - I spoke too soon.

It fixes the problem in Manjaro 18.0.2, but not in Linux Mint 18.3.

[draco (draco31-fr)]

You should be able to change the default settings with lpoptions command :
https://www.cups.org/doc/man-lpoptions.html?TOPIC=Man+Pages

Take care of the default page format first, and check also the page
dimension, it could be wrong for this format.

Le mer. 9 janv. 2019 à 20:50, unfa <email address hidden> a écrit :

> Oh wait - I spoke too soon.
>
> It fixes the problem in Manjaro 18.0.2, but not in Linux Mint 18.3.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/293832
>
> Title:
> printer prints page at wrong position, page cut
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/poppler/+bug/293832/+subscriptions
>