pdftops CUPS filter has several problems

[Till Kamppeter]

In the beginning, CUPS shipped a pdftops filter based on the /usr/bin/pdftops utility of Poppler. It produces DSC-conforming PostScript which can easily be processed by further filters. It also leaves text as text and embeds the fonts. Its problem is that it does not support documents with multiple page sizes. In this case it scales all pages to the size of the first page (bug 310575, https://bugs.freedesktop.org/show_bug.cgi?id=19777).

To get around that, and also in the hope to get color management working more quickly, I switched to Ghostscript for the pdftops filter in CUPS. It solved the multiple-page-size problem perfectly but caused several other problems.

I started with the "pswrite" output device of Ghostscript. Its output is also DSC-conforming, but it turns all text characters to bitmaps, causing huge PostScript files (bug 377011), broken text characters (bug 362186), slow job processing (bug 289852), output files which are not searchable (bug 381788).

So I tried the "ps2write" output device of Ghostscript. Its output is not DSC-conforming, so it can only be used in the pdftops filter when the PDF workflow is used, where the page manipulations are done by the pdftopdf filter which runs always before pdftops. In the upstream CUPS without filter additions incoming PDF is turned to PostScript by the pdftops filter and after that the pstops filter does the page management and this requires DSC-conforming PostScript. It actually solved the problems of "pswrite" producing a PostScript of reasonable size and with embedded fonts, but it is still not perfect, for example it produces code which does not run on some PostScript printers (bug 377011) and the text searchability is also not perfect (bug 381788).

As it turns out that Ghostscript has too many problems in its two PostScript output devices, I am looking into returning to Poppler, as they have only the one minor problem of the multiple page size output, which I have fixed. I have submitted the patch upstream (see https://bugs.freedesktop.org/show_bug.cgi?id=19777) and I also attach a debdiff for the Ubuntu package of Poppler. This adds a new output mode to the PostScript output device of Poppler which conserves the original page sizes and orientations.

Once this new Poppler versions is uploaded, we can change the pdftops filter of CUPS to use Poppler and patch it to use the new "-origpagesizes" option for the /usr/bin/pdftops call.

[Albert Astals Cid (aacid)]

That's more a wish than a bug, in the sense that pdftops was never ment to output different page sizes per page :D But i accept this is interesting

It is not much difficult, it would involve adding an option to PSOutputDev to tell him not to use just one page size and then output
  <</PageSize [a b ] >> setpagedevice
after
%%BeginPageSetup

But at the moment i don't have any time to fix it, i'll put it in the top-ish part of the TODO but that doesn't mean it will ever be done. If someone can work on it, drop a note here.

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=26338)
Patch to add support for multiple page size output

The attached patch fixes the problem by adding a new "-origpagesizes" output mode to the "pdftops" utility.

pdftops -origpagesizes combined.pdf

produces the expected output as combined.ps with combined.pdf being the attached sample PDF file.

The patch works as described by Albert Astals Cid in comment #1. The PostScript output device gets a new output mode psModePSOrigPageSizes. If it is selected pages do not get scaled and rotated into a given output page size, but the original page sizes are conserved and none of the pages gets rotated. The page headers contain page size requests of the form

<</PageSize [<width> <height>]>> setpagedevice

to make a printer switching to the appropriate paper tray.

The patch does not change the API or default behavior of Poppler. The new mode is only used when explicitly selected.

[Till Kamppeter (till-kamppeter)]

In the beginning, CUPS shipped a pdftops filter based on the /usr/bin/pdftops utility of Poppler. It produces DSC-conforming PostScript which can easily be processed by further filters. It also leaves text as text and embeds the fonts. Its problem is that it does not support documents with multiple page sizes. In this case it scales all pages to the size of the first page (bug 310575, https://bugs.freedesktop.org/show_bug.cgi?id=19777).

To get around that, and also in the hope to get color management working more quickly, I switched to Ghostscript for the pdftops filter in CUPS. It solved the multiple-page-size problem perfectly but caused several other problems.

I started with the "pswrite" output device of Ghostscript. Its output is also DSC-conforming, but it turns all text characters to bitmaps, causing huge PostScript files (bug 377011), broken text characters (bug 362186), slow job processing (bug 289852), output files which are not searchable (bug 381788).

So I tried the "ps2write" output device of Ghostscript. Its output is not DSC-conforming, so it can only be used in the pdftops filter when the PDF workflow is used, where the page manipulations are done by the pdftopdf filter which runs always before pdftops. In the upstream CUPS without filter additions incoming PDF is turned to PostScript by the pdftops filter and after that the pstops filter does the page management and this requires DSC-conforming PostScript. It actually solved the problems of "pswrite" producing a PostScript of reasonable size and with embedded fonts, but it is still not perfect, for example it produces code which does not run on some PostScript printers (bug 377011) and the text searchability is also not perfect (bug 381788).

As it turns out that Ghostscript has too many problems in its two PostScript output devices, I am looking into returning to Poppler, as they have only the one minor problem of the multiple page size output, which I have fixed. I have submitted the patch upstream (see https://bugs.freedesktop.org/show_bug.cgi?id=19777) and I also attach a debdiff for the Ubuntu package of Poppler. This adds a new output mode to the PostScript output device of Poppler which conserves the original page sizes and orientations.

Once this new Poppler versions is uploaded, we can change the pdftops filter of CUPS to use Poppler and patch it to use the new "-origpagesizes" option for the /usr/bin/pdftops call.

[Martin Pitt (pitti)]

Thanks, Till! I agree that under the current conditions returning to pdftops from poppler is reasonable.

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=26393)
Improved patch to add support for multiple page size output

I have improved the patch somewhat. With the original patch there were no "%%PageBoundingBox:" comments and then the pstops CUPS filter added them to each page, but always using the default page size from the PPD file. Now correct "%%PageBoundingBox:" comments are directly added and sp pstops does not add its own any more. I do not know whether this behavior of pstops would break anything for printing with changing paper sizes, but better to have it right.

[Till Kamppeter (till-kamppeter)]

Here is an updated debdiff with the improved patch as also attached to the upstream bug report. In addition, each page gets a %%PageBoundingBox: comment now, so that CUPS' pstops filter does not add its own %%PageBoundingBox: comment with the PPD default page size to each page header.

[Albert Astals Cid (aacid)]

should -origpagesizes conflict with -paper, -paperw, -paperh?

Could you also add the switch to the man page?

[Till Kamppeter (till-kamppeter)]

Currently, -origpagesizes overrides -paper, -paperw, -paperh, at least if the input file specifies paper sizes for its pages. But is it possible to have a PDF not specifying its paper sizes, like the PostScript file /usr/share/cups/data/testprint.ps (CUPS test page)?

[Albert Astals Cid (aacid)]

hmmm, yeah, no idea what this could mean, leave like it is for now.

Well, what about adding the documentation to the man page?

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=26408)
Patch for the pdftops man page

Here we go: The patch for the updated man page of pdftops.

[Till Kamppeter (till-kamppeter)]

Created an attachment (id=26409)
Complete updated man page of pdftops

This is the complete updated man page of pdftops.

[Till Kamppeter (till-kamppeter)]

This fixes also bug 372166.

[Albert Astals Cid (aacid)]

Commited to master

[Till Kamppeter (till-kamppeter)]

Added the fix for bug 335397 to the debdiff. This bug also needs to be fixed to avoid a regression.

[Launchpad Janitor (janitor)]

This bug was fixed in the package poppler - 0.11.0-0ubuntu3

---------------
poppler (0.11.0-0ubuntu3) karmic; urgency=low

  * debian/patches/15_poppler-ps-output-broken-binary-encoding-fix.patch:
    Fixed bug in copying ASCII85-encoded binary data from the PDF input
    file which produced broken PostScript (LP: #335397).
  * debian/patches/10_pdftops-multiple-page-size-support.patch: Added new
    output mode to the PostScript output device, so that the original page
    sizes of PDF documents with multiple page sizes stay conserved
    (LP: #382379).

 -- Till Kamppeter <email address hidden> Thu, 4 Jun 2009 18:24:49 +0200

[Till Kamppeter (till-kamppeter)]

This fixes also bug 375763.

[Till Kamppeter (till-kamppeter)]

The needed CUPS patches are now uploaded to the BZR repository at Debian and soon a package for Karmic will be uploaded. The new Poppler package is already available for Karmic.

For the time being please keep on testing with my pdftops test script and report everything what you observe. Also everyone who reads this bug report without being affected by the mentioned problems is encouraged to test my pdftops filter or the upcoming Karmic package of CUPS.

The next step will be an SRU (Stable Release Update) of Jaunty's Poppler and CUPS packages, so that the problems get solved for Jaunty users.

[Till Kamppeter (till-kamppeter)]

Attached is my Poppler-based pdftops CUPS filter. This filter is a shell script which is equivalent in functionality with the pdftops filter of the upcoming CUPS package for Karmic.

Everyone, please test with this filter whether the Poppler-based pdftops filter solves your problems. Report any problem here and in the case of a problem, please attach an error_log following the instructions in the "CUPS error_log" section of

https://wiki.ubuntu.com/DebuggingPrintingProblems

To install the attached filter on your system, download the file and replace your /usr/lib/cups/filter/pdftops file by it. Make sure that the new file is executable, run the command

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

if needed.

Should this break printing for you and you need to print urgently, run the command

sudo apt-get install --reinstall cups

to get back to the previous configuration.

If printing works for you with my filter, DO NOT reinstall CUPS, we need as much testing as possible.

[Till Kamppeter (till-kamppeter)]

Sorry, attached the wrong file. Here is the correct one:

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.3.10-3

---------------
cups (1.3.10-3) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/cups.install, debian/rules: Move added *.convs and *.types files to
    /usr/share/cups/mime/ so that they are not considered config files
    by dpkg.
  * debian/local/text.convs: Turn all text input formats to text/plain at
    a high cost, so that the text-only printer (which accepts only text/plain)
    accepts them (LP: #385797).
  * debian/rules: Switch the pdftops filter back to Poppler, as Ghostscript
    has a lot of problems in generating PostScript (LP: #382379).
  * debian/patches/poppler-based-pdftops-fixes.dpatch: Fixes for the pdftops
    filter in Poppler mode: Do not emit PostScript level 3 as it Poppler's
    PostScript level 3 output is not compatible with HP's PostScript printers
    (LP: #277404); Added support for the new "-origpagesizes" option of
    Poppler's pdftops, so that documents with pages of different sizes get
    correctly printed (LP: #310575).
  * debian/filters/pstopdf: Do not call Ghostscript with asymmetric resolutions
    (like 1200x600 dpi), as it leads to problems with images in some cases.
    See http://bugs.ghostscript.com/show_bug.cgi?id=690504.
  * debian/local/filters/pdf-filters/pdftopdf/P2PObject.h,
    debian/local/filters/pdf-filters/pdftopdf/P2POutput.cxx: Fixed infinite
    loop which occured for some PDF files (LP: #382880).
  * debian/filters/pstopdf: Make it also correctly working if PaperDimension
    and ImageableArea entries in the PPD have no translation strings. Thanks
    to Koji Otani to find the bug.
  * debian/local/filters/pdf-filters/pdftoopvp/,
    debian/local/filters/pdf-filters/README,
    debian/local/filters/pdf-filters/addtocups,
    debian/local/filters/pdf-filters/removefromcups,
    debian/local/filters/pdf-filters/config-scripts/cups-pdf-filters.m4:
    Added pdftoopvp CUPS filter as part of the PDF filter add-on.
  * debian/cups.install: Make /etc/fonts/conf.d/99pdftoopvp.conf of pdftoopvp
    be installed as part of the cups package
  * debian/control: Added build dependencies needed by pdftoopvp: liblcms1-dev,
    libfreetype6-dev, libfontconfig1-dev
  * debian/control: Moved dependency on cups-client to Depends:, as
    cups-client is needed by the post-install script for the update of the
    PPDs of existing print queues.
  * debian/cups.postinst: Case-insensitive check for model names when updating
    PPDs of already existing print queues.

  [ Martin Pitt ]
  * Add gnutls-pkgconfig.dpatch: Use "pkg-config gnutls" instead of deprecated
    libgnutls-config. (Closes: #529903)
  * Bump Standards-Version to 3.8.1 (no changes necessary).
  * debian/control: Point Vcs-Browser: to bzr.d.o. loggerhead, and use http://
    URL for Vcs-Bzr.
  * debian/control: Drop ghostscript build dependency again, pdftops filter
    uses poppler again. Also Drop alternative xpdf-utils build dependency,
    since configure now checks for poppler's pdftops capabilities.
  * debian/control, debian/rules: Do a build-time check if pdftops supports
    -origpagesizes, and dynamically set the poppler-utils dependency. This is
    a hack until https:/...

[DFreeze (dfreeze)]

A quick hurray coming from someone experiencing bug #362186 (HP LaserJet 2200 DN). I too had the little stripes above characters, but the fix provided in that thread did fix it for me too. Thanks!

[Till Kamppeter (till-kamppeter)]

Please test the current Karmic, especially regarding the problems mentioned below. They all should have gone. Please report your success and/or problems here.

Confirmed that the Poppler-based pdftops CUPS filter fixes the following bugs:

bug 377011: Cannot print documents to Laserjet 4350, via network
bug 362186: Spurious lines on print outs
bug 289852: intrepid: printing very slow (at least partially)
bug 381788: [jaunty] cups-pdf no longer embeds fonts in pdf file
bug 372166: No output when printing in Ubuntu 9.04
bug 361772: black squares appearing instead of some letters when printing

This I have fixed in Poppler:

bug 335397: Poppler's pdftops fails to convert a PDF file to PostScript

This I have fixed/worked around by patching the pdftops CUPS filter to never let Poppler generate PostScript level 3:

bug 277404: hp laserjet postscript text print does not print some characters

This does not need to be done any more, I have fixed Poppler appropriately:

bug 329991: Poppler's pdftops does not support multiple-page-size output, use Ghostscript for the CUPS filter instead

For this bug I have no information about its current state, neither whether any GhostScript-based pdftops filter solves it nor whether the new Poppler-based one or any change in Poppler fixes it. Please test.

bug 293832: (Brother PostScript) printer prints page at wrong position, page cut

Please check also:

bug 310575: A3 pdf file is cropped and printed on A4 paper
bug 310854: Printing Photos with Canon original drivers stopped working in Intrepid

[Till Kamppeter (till-kamppeter)]

Also confirmed that the Poppler-based pdftops CUPS filter fixes:

bug 378068: Unsatisfactory Quality on Samsung CLP-315 Color Laser Printer (foomatic)

[adonet (jeroen-adolfse)]

In Linux Mint 7 the last pdftops is working.
That is: I tested it on printing this very webpage from firefox on a networked HP Laserjet 4000 printer and it comes directly out of the printer with the recommended Postscript printerdriver. Also first print to a pdf file and print that file from evince works OK. The result is the same.
Only the list of subscribers is printer through the other text, but that also happens when making a pdf
I didn't test other applications yet.

I have to thank Till Kamppeter very much !!!!!

[Till Kamppeter (till-kamppeter)]

The problem with the subscriber list is a bug of your browser (most probably Firefox) as it already appears when printing to PDF (an operation which does not involve the printing system. So report a Firefox bug for that.

[NoOp (glgxg)]

While I'd love to report that all is well (see: https://bugs.launchpad.net/bugs/382379), I think that there are still serious issues. (Sorry Till, but you'd ask that we test).

Attached are three test files of an svg drawing with text:

1. Example_printwcups.pdf is printed to pdf via cups & Till's latest pdftops.
2. Example_savedfromInkscape.pdf is a pdf using 'save as' Inkscape pdf (using cairo).
3. Example_printtofile.pdf is the same svg using print to file.

Note that #1 is 97.4Kb and prints to pdf only as a graphic (no fonts, no text).
#2 is 23.2Kb and embeds the Arial text font and the dejavusansbold font for the numbers on the graphic.
#3 is 23.6Kb and also properly embeds the fonts.

Also notice the graphic qualities in #1 vs #2&3; the lines do not render clean (jags) & is most apparent on the green lines.

[Till Kamppeter (till-kamppeter)]

NoOp, can you post the original SVG file, so that I can do some testing with it? Thanks.

Can you also try with Intrepid (Live CD, other machine) whether the problem was already there? Do not replace Intrepid's pdftops filter for that test. Can you also test with Jaunty without filter replacement ("sudo apt-get install --reinstall cups") to check which is worse, Intrepid or Jaunty. This information we need to see whether we can do a Stable Release Update (SRU, backport of this fix to Jaunty) in Jaunty,

The bad quality can also be caused by cups-pdf. The fix of bug 385709 would be the solution then.

[NoOp (glgxg)]

Till, attached is the svg file. I'll do the other tests later this afternoon & post back with the results. The svg is created in inkscape 0.46-5ubuntu4.

[Till Kamppeter (till-kamppeter)]

The problem is Poppler's pdftops filter. It turns the PDF file which was generated by inkscape and sent to CUPS to a graphics-only PostScript file. Seems to be an upstream bug of Poppler. Usually Poppler conserves the text when converting PDF to PostScript (at least it did so with PDFs coming from other applications and PDFs which CUPS generated from PostScript files with Ghostscript).

The best and easiest solution for your situation would be the fix of bug 385709 so that PDF files do not get converted to PostScript and back to PDF when cups-pdf is used. For now you should always use the PDF generation facility inside the applications and use the PDF printer only for applications which do not have PDF export functionality by themselves.

[Till Kamppeter (till-kamppeter)]

According to the source code of Poppler's PostScript output facility pages get rasterized at 300 dpi if they use transparency. Does your drawing use transparency?

As PostScript by itself does not support transparency, we need a PDF printing workflow which is as complete as possible. Drivers should be designed to accept PDF (most printer drivers do, as they use Ghostscript). Conversion from PDF to PostScript should be avoided, it should only be done to print on PostScript printers.

[NoOp (glgxg)]

Sorry... I think that is not the problem.

I brought up hardy on a test machine using the liveCD, installed Inkscape: 'sudo apt-get install inkscape' (again this is a liveCD session - nothing installed to the hard drive), copy over the Example_testfile.svg file from this machine, opened it in Inkscape, selected File|Print, selected the automatically installed cups-pdf printer that is installed with the liveCD, made zero adjustments to the settings, printed to PDF, and the result is a proper PDF. See the attached.

I'll have to download an burn an intrepid liveCD as I only have an intrepid alternate CD. I have an intrepid hard drive in the box somewhere, but prefer to try from the liveCD so that any previous users settings do not affect the test.

[Till Kamppeter (till-kamppeter)]

Note that cups 1.3.10-3 and 1.3.10-4 are broken and cannot be used for testing whether this bug got fixed. Please wait until 1.3.10-5 becomes available or test with 1.3.10-2 and my atttached pdftops filter.

[Till Kamppeter (till-kamppeter)]

NoOp, Hardy had a completely different workflow, here Inkscape produced PostScript, CUPS did page management on PostScript and then cups-pdf turned the PostScript to PDF with Ghostscript. Ghostscript's "pdfwrite" output device does not turn text characters into bitmaps.

From Intrepid on, the printing workflow is PDF-centric. Applications are supposed to send PDF to CUPS, like many applications including Inkscape do, and CUPS to do the page management on PDF. The pdftops filter of CUPS is primarily a PostScript printer driver in this scenario, but also a fallback if some printer driver is not adapted to the new workflow, like cups-pdf.

Most printer drivers are raster drivers, and printed paper you cannot magnify arbitrarily. So there the rasterization of the document by the pdftops driver is no big problem. cups-pdf plays a special role as it is a vector driver creating PDFs for screen view, with the option of arbitrary magnification. The best output quality you get here if you avoid unneeded conversions. Therefore I have reported bug 385709 where I suggest simple changes in cups-pdf to accept PDF directly to avoid conversion to PostScript and back to PDF.

cups-pdf is also not necessarily needed nowadays, as most applications (at least all KDE and GNOME applications, and also OpenOffice.org) can generate PDF without a special CUPS queue, either via "Print to file" or via "Export as PDF". Therefore cups-pdf was already demoted to Universe and not shipped on the CDs any more.

[Till Kamppeter (till-kamppeter)]

NoOp, I have fixed bug 385709 in Karmic now. So there your drawing should get PDF-printed in the original quality of Inkscape now.

[NoOp (glgxg)]

Excellent! Is there a way that this can be enabled in jaunty proposed for testing?

[Till Kamppeter (till-kamppeter)]

As all bugs referenced here (and linked as duplicates) are regressions in Jaunty, we decided to issue the fix (switching pdftops back to Poppler, fixing Poppler bugs to avoid other regressions) as an SRU for Jaunty.

debdiffs and insructions for testing the updated CUPS and Poppler packages in jaunty-proposed will follow ...

[Lennart Jütte (accounts-rtjuette)]

> None of the above problems deals with a scanned image or 80-page document. Is there any additional problem with these kinds of documents if you actually print them (not print them to PDF)?

I have problems when printing certain pdf-documents that contain big (scanned) images or have a lot of pages (40+). The printer just prints only the first 1 or 2 pages and then stops. I can't tell if it's related to the update that was released a few days ago because i just acuired these documents and haven't printed them before. But other "big" documents weren't a problem before.

If you're interested in debug output and example documents, just tell me!

[Till Kamppeter (till-kamppeter)]

Lennart Jütte, can you please attach the files which cause problems for you and can you also attach the error_log when printing them? Please see the section "CUPS error_log" in https://wiki.ubuntu.com/DebuggingPrintingProblems for how to get the correct error_log.

[Lennart Jütte (accounts-rtjuette)]

Sorry, i couldn't reproduce the problem. Maybe it was just a one-time-incident. I had to reboot the machine after the jobs failed - everything works (almost) fine now.

If the problem occurs again i'll post my logs here.

[Steve Dodd (anarchetic)]

Martin wrote on ubuntu-devel:

> I'm actually more concerned about also testing printers which work
> fine in Jaunty. I can help out with a Samsung ML-1610, and I guess
> Till can throw his armada of printers at it which he has at home, but
> we should send out an extra call for testing in blogs and
> ubuntu-devel.

Everyday printing tasks (web pages, short letters, etc.) seem to work fine on my ancient HP DeskJet 840C with Karmic. I never hit the multiple page sizes problem, and I never got around to installing Jaunty, so I can't specifically confirm that those problems are fixed, but FWIW I can say that everything seems to work at least as well in Karmic as in Hardy.

[Jesse (sbjesse)]

I'm not sure if my problem is related to the pdftops filter but it's certainly worse than before.
I installed the fix from proposed:
$ sudo apt-get install -t jaunty-proposed cups
and then i added the LJ4000 printer in our office via samba
then i printed the attached postscript file, the result is disastrous: only the title, the footnote, and the maths are printer, the text almost completely disappeared!

[Till Kamppeter (till-kamppeter)]

Jesse, I have checked your problem and the files gets broken already by the pdftopdf filter which is used before pdftops is called. So the replacement of pdftops will not have caused this problem.

The pdftopdf problem I have reported to the author of the filter.

[Jesse (sbjesse)]

again, i'm not sure if this is pdftops's fault, but my duplex print jobs constantly get printed out as two-up with right-to-left page-order...
attached is the postscript generated by "dvips -Plj4k". Running "lpr tp.ps" would produce the strange printout.
my printer in office: hp laserjet 4000n, protocol: samba.
driver/ppd lj4000 hpijs
printer options: duplex unit, a4 media size, flip on long edge
job options: a4 paper size, 1 page per side, flip on long edge

@till indeed i tried the old cups in intrepid, and sadly, yes it broke my last postscript file too...

[Jesse (sbjesse)]

thought this could help: i set up an intrepid system with kvm and printed tp.ps with the cups in the virtual machine and it runs fine

[Till Kamppeter (till-kamppeter)]

Jesse, for me the file comes out correctly. Can you attach the PPD file (from /etc/cups/ppd/) and an error_log of a job which comes out incorrectly? For the error_log follow the instructions in the "CUPS error_log" section on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

[Jesse (sbjesse)]

@till this is the hpijs ppd file. i've also tried the "recommended" one, it didn't work either.

[Jesse (sbjesse)]

@till this is the error_log you asked for. sorry for messing it up with a lot of samba login fail coz i didn't save password.

[Jesse (sbjesse)]

my amateur eyes spot this spooky line in the log:
D [10/Jul/2009:01:55:45 +0800] [Job 13] argv[5]="media=A4 sides=two-sided-long-edge finishings=3 number-up=2 PageSize=A4 PrintoutMode=Normal InputSlot=Default Duplex=DuplexNoTumble Quality=FromPrintoutMode nocollate outputorder=normal number-up-layout=rltb nowrap position=center job-uuid=urn:uuid:25ec42b8-fdd0-39d0-5b3b-0e92b3da26a4"

i never touched the "left to right, top to bottom" (rltb) drop-down in the printer options, nor did i choose "2 sides per page" (number-up=2). the displayed settings (default) are "left-to-right, top to bottom" and "1 side per page".

i feel guity for printing this much today :)
shalom!

[Till Kamppeter (till-kamppeter)]

Jesse, can you check (and attach) the following files:

/etc/cups/printers.conf
/etc/cups/lpoptions
~/.cups/lpoptions

The first file will contain default settings if you change the "Job Options" in system-config-printer. The second will be used if you save options in a printing dialog of an application which is running as root. The third will be used if you save options in the printing dialog of an application running as yourself.

[Jesse (sbjesse)]

till, you are right! my ~/.cups/lpoptions mysteriously contained the two-up option... but i can hardly remember where i set it or saw it! just now i tried starting evince and print, and i can't see the two-up being set in evince! what apps will 'see', or recognize that option? guess evince and many other apps just never noticed it but still let it slipped in under the hood

my printers.conf:
# Printer configuration file for CUPS v1.3.9
# Written by cupsd on 2009-07-10 01:55
<DefaultPrinter lp116>
AuthInfoRequired username,password
Info HP LaserJet 4000
Location Rm115
DeviceURI smb://ntsvr4/lp116
State Idle
StateTime 1247162145
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
Option media A4
Option sides two-sided-long-edge
</Printer>

my ~/.cups/lpoptions
Default lp116 number-up=2 PageSize=A4 PrintoutMode=Normal InputSlot=Default Duplex=DuplexNoTumble Quality=FromPrintoutMode collate=false outputorder=normal number-up-layout=rltb wrap=false position=center
Dest PDF PageSize=A4 Resolution=300dpi collate=false outputorder=normal number-up=2 wrap=false position=center fitplot=true

[Till Kamppeter (till-kamppeter)]

AFAIK KDE apps save printer settings in ~/.cups/lpoptions.

[Daniel (damendieta)]

I can't download (even see) the file.

Can you please give some more information about the install process?

Thanks

[Till Kamppeter (till-kamppeter)]

Daniel, ~/.cups/lpoptions is only created when the printer options are saved by certain applications, like KDE applications for example. So not every user has this file.

Do you have any problems, like for example that all jobs get printed 2 pages per sheet?

[FMaz (fmaz008)]

Just to confirm that I have the same problem with 2 of my Ubuntu 9.04 computers with a Brother HL-2070w, in network mode.

This problem have also been mentionned by users here:
http://ubuntuforums.org/showthread.php?t=411815
http://forum.ubuntu-fr.org/viewtopic.php?pid=2979174

If you need any informations, I'll be glad to help you with that; I just need explicit/simple procedures on how to obtain what is required.

[craigbass76 (craig-dorunwebservices)]

I still couldn't print well this morning to a networked Brother MFC 7820N, using a plethora of pdf viewers in both Jaunty and Karmic (with updated related --cups, etc-- packages)

However, I happened across an old forum post where someone with Dapper used the HP laserjet foomatic driver for this printer instead. So I tried it in the Karmic livecd environment and fell out of my chair when ALL pages of a pdf printed in less than a minute.

Further amazement ensued when the same thing happened to me in Jaunty. I'm all fixed now.

My symptoms were some of the same described here; slow or no printing of pdf, printing only one page of a graphics heavy pdf, etc, etc.

I was using the .deb driver from Brother's website.

[Till Kamppeter (till-kamppeter)]

Unfortunately, my last patch has still problems and I need someone to help me to get PostScript with varying page sizes and with preservation of page independence and also without breaking duplex. See

http://www.cups.org/str.php?L3689

Thanks in advance.

[Adrian Johnson (ajohnson-redneon)]

Testing setpagedevice on my printer it seems that if setpagedevice is called after printing one side in duplex mode, the next page will not be on the second side but instead start on a new sheet of paper.

If you want to call setpagedevice on each page to allow pages to be reordered you could emit PS code that checks if the required page size is already selected before calling setpagedevice.

Something like:

  currentpagedevice /PageSize get aload pop
  842 ne exch 595 ne and
  {
      <</PageSize [595 842]>> setpagedevice
  } if

I don't think save/restore is required because poppler reinitializes the gstate parameters used at the start of each page.

I would also be interested to know why pdftops when used as a CUPS filter needs tp emit setpagedevice directly instead of using the "%%IncludeFeature" style comments as described at http://www.cups.org/documentation.php/doc-1.4/spec-postscript.html and letting CUPS insert the page select PS code based on the PPD file.

[zcat (zcat)]

Is this fixed? Less than a month ago I installed 10.04 on a compaq laptop, printing to a network laser printer (can't recall the model). Everything fully up to date at the time, but it's printing PDF's at glacial speed and holding up everyone else's print jobs. Windows users in the same office have no problems (except when an ubuntu printjob is blocking them)

It's been a problem for a while, I was hoping a fresh install of 10.04 would fix it, previous laptop was still running 9.10 and also had the same problem.

If I just update 10.04 will the problem fix itself now? Or should I try the poppler workaround mentioned earlier?

[GT (gleppert)]

I use an up-to-date Ubuntu 10.04 as well. The problem is still there and
it is very annoying. Still exactly the problem as "zcat" described it.
I encounter the problem with a Kyocera FS-3830N and also with an
KonicaMinolta BizHub C220. All other users in the office are always
annoyed when I need to print a PDF (e.g. a presentation).

[GT (gleppert)]

Sending a ping regarding this bug. The problem is still existing. Printing over the network is terribly slow with larger PDFs or PDFs containing a large (scanned) image.
For this bug, it says, there are fixes released, but the bug itself is open. When will the fixes be pushed to Ubuntu? Thanks.

[Till Kamppeter (till-kamppeter)]

Aldi, please see bug 668800 about remaining rendering slowness problems. This is fixed in the newest version of Ghostscript (which is already included in Oneiric). See also the appropriate upstream bug http://bugs.ghostscript.com/show_bug.cgi?id=690475. In addition, Ghostscript's rendering gets faster by adding "-dNOINTERPOLATE" to the Ghostscript command line (see comment in the end of the upstream bug). In Oneiric this is now done in all printer drivers and print filters which use Ghostscript, so here overall printing (except native PostScript printers fed with PostScript jobs) should get significantly faster.

[GT (gleppert)]

Till, thanks a lot for the fast and great answer. I am looking forward to Oneiric and I will try the rendering trick. Thanks.

[NoOp (glgxg)]

On 07/26/2011 01:53 PM, Till Kamppeter wrote:
> Aldi, please see bug 668800 about remaining rendering slowness problems.
> This is fixed in the newest version of Ghostscript (which is already
> included in Oneiric). See also the appropriate upstream bug
> http://bugs.ghostscript.com/show_bug.cgi?id=690475. In addition,
> Ghostscript's rendering gets faster by adding "-dNOINTERPOLATE" to the
> Ghostscript command line (see comment in the end of the upstream bug).
> In Oneiric this is now done in all printer drivers and print filters
> which use Ghostscript, so here overall printing (except native
> PostScript printers fed with PostScript jobs) should get significantly
> faster.
>
> ** Bug watch added: Ghostscript (AFPL) Bugzilla #690475
> http://bugs.ghostscript.com/show_bug.cgi?id=690475

Till, will any of this be backported to Maverick & Natty?

[Till Kamppeter (till-kamppeter)]

NoOp, the new Ghostscript version would be a too high impact for an SRU, but the adding of "-dNOINTERPOLATE", at least for very common drivers and filters would be possible. You could try it out, at least if it is currently a Ghostscript process which slows down your printing (check with "top"). Can you find out which filter (and whether it is Poppler or Ghostscript) is the culprit for you now?

[NoOp (glgxg)]

Till, will do. I may not be able to get to it until tomorrow, but I'll see if I can pin it down. Thanks.

[Till Kamppeter (till-kamppeter)]

For the problem of comment #78, we work on it in bug 780935.

[Leo (leorolla)]

This problem is back in Oneiric.

[Leo (leorolla)]

Till, NoOp, others,

Is there a workaround for this?

The solution in
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/381788/comments/17
didn't work, see file attached.

[Bug Reporter 11 (bugreporter11)]

This bug is being proposed as the problem related to this questsion: http://askubuntu.com/questions/118862/how-can-i-set-print-to-file-as-my-default-printing-option. However, I'm not sure that's accurate. Just an FYI.

[Peter Hedlund (peter-peterandlinda)]

This problem is still present in Precise. I just printed this page. Cups-pdf took several minutes, spiked one cpu core and finally generated a 5.9 MB file with the pages rendered as images. The Firefox built-in pdf printer took a few seconds and generated a 218 KB file with the pages rendered as text.

[Uwe Mock (u-mock)]

Confirmed. Here it was gs that hogged the cpu core, and my file grew to 1.8 MB containing only bitmaps.
Howdo I access that pdf printer built into Firefox?

[Martin Wildam (mwildam)]

I am on Ubuntu 12.04 and experiencing the problem with whatever filter that has been posted or referenced here. Did not have that problem on 10.04 - tried also with the pdftops filter from there without luck. Sad...

[Martin Wildam (mwildam)]

I found that I still have poppler-utils 0.18.4 although at the top in launchpad I can see that 0.20.2 should be the most current. Switched to main server in synaptic but still no update.
BTW: I am on 64-bit.

[Marius B. Kotsbak (mariusko)]

I see the upstream bug report is reopened. Someone experiencing this problem should open a new bug report about the remaining problems and link the upstream report.

[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/208.