printer prints page at wrong position, page cut

Bug #293832 reported by somebody74 on 2008-11-04
This bug affects 19 people
Affects Status Importance Assigned to Milestone
brother-cups-wrapper-extra (Ubuntu)
brother-lpr-drivers-extra (Ubuntu)
cups (Ubuntu)
Till Kamppeter
poppler (Ubuntu)

Bug Description

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) wrote :

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?

Changed in brother-cups-wrapper-laser:
status: New → Incomplete
somebody74 (steffenwittkamp) wrote :

Yes, that's correct.

Changed in brother-cups-wrapper-laser:
status: Incomplete → New
Saivann Carignan (oxmosys) wrote :

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) wrote :

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) wrote :

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

somebody74 (steffenwittkamp) wrote :

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

Till Kamppeter (till-kamppeter) wrote :

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) wrote :

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) wrote :

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

somebody74 (steffenwittkamp) wrote :

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.

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

Do not forget to make the filter world-executable.

Does printing work correctly for you now?

Changed in foomatic-db:
importance: Undecided → High
status: New → Incomplete
Martin Pitt (pitti) wrote :

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

Please see for documentation how to enable and use -proposed.

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
cat \$6
chmod 755 /usr/lib/cups/filter/pdftopdf

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) wrote :

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

somebody74 (steffenwittkamp) wrote :

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) wrote :

Okay, here is the printout that hardy generates

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/


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

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) wrote :

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.

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) wrote :

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/

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) wrote :

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.


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.

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) wrote :

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

Error message:

P2POutputStream:write error

I attached the more detailed error message I got.

I am attaching another version. please try it.


especially comments

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.

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


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

Reported Poppler problem upstream:

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

Changed in cups:
status: New → Incomplete
importance: Undecided → High

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.

somebody74 (steffenwittkamp) wrote :

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

Changed in poppler:
status: Unknown → Confirmed

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

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

Serge van Ginderachter (svg) wrote :

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!

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

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 (

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)

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

Changed in cups:
assignee: nobody → till-kamppeter
Changed in brother-lpr-drivers-extra (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Changed in brother-cups-wrapper-extra (Ubuntu):
importance: Undecided → High
status: New → Incomplete
53 comments hidden view all 133 comments

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.

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?

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) wrote :

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) wrote :

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

ferrouswheel (joel-pitt) wrote :

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) wrote :

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) wrote :

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 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) wrote :

OK, installing the

  brother-cups-wrapper-laser package

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

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) wrote :

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) wrote :

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

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

See the patch attached in this bug report against IceApe:

This bug report also claims that the PageSize policy is to be blamed:

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

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

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.

Changed in poppler (Ubuntu):
status: Incomplete → Fix Committed

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

Changed in cups (Ubuntu):
status: Incomplete → Invalid
Changed in brother-lpr-drivers-extra (Ubuntu):
status: Incomplete → Invalid
Changed in brother-cups-wrapper-extra (Ubuntu):
status: Incomplete → Invalid
Launchpad Janitor (janitor) wrote :

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

Changed in poppler (Ubuntu):
status: Fix Committed → Fix Released

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.

Changed in cups (Ubuntu Karmic):
status: New → Invalid
Changed in brother-lpr-drivers-extra (Ubuntu Karmic):
status: New → Invalid
Changed in brother-cups-wrapper-extra (Ubuntu Karmic):
status: New → Invalid
Changed in poppler (Ubuntu Karmic):
status: New → Fix Committed
importance: Undecided → Medium
importance: Medium → High

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.

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.

Changed in poppler (Ubuntu Karmic):
milestone: none → karmic-updates

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

tags: added: verification-needed

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?

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

Raid996 (khyaninlot) wrote :

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) wrote :

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

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) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in poppler (Ubuntu Karmic):
status: Fix Committed → Won't Fix
Changed in poppler:
importance: Unknown → High
4 comments hidden view all 133 comments

The patch applied to Ubuntu Lucid and proposed in:
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?

Changed in poppler:
importance: High → Unknown
Changed in poppler:
importance: Unknown → High
3 comments hidden view all 133 comments


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) wrote :

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

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

Fiorenzo De Santis (fiod3s) wrote :

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

Mathew Hodson (mhodson) on 2014-06-01
tags: removed: verification-needed
1 comments hidden view all 133 comments

-- GitLab Migration Automatic Message --

This bug has been migrated to'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:

Changed in poppler:
status: Confirmed → Unknown
1 comments hidden view all 133 comments

Spam alert ...

unfa (unfa00) wrote :

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) wrote :

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) wrote :

Oh wait - I spoke too soon.

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

You should be able to change the default settings with lpoptions command :

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.
> Title:
> printer prints page at wrong position, page cut
> To manage notifications about this bug go to:

Displaying first 40 and last 40 comments. View all 133 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.