pdftops CUPS filter has several problems
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Poppler |
Unknown
|
Medium
|
|||
cups (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Unassigned | ||
poppler (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Unassigned |
Bug Description
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:/
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:/
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.
In freedesktop.org Bugzilla #19777, Albert Astals Cid (aacid) wrote : | #1 |
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #2 |
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 psModePSOrigPag
<</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) wrote : | #3 |
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:/
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:/
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.
Changed in cups (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in poppler (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in poppler: | |
status: | Unknown → Confirmed |
Till Kamppeter (till-kamppeter) wrote : | #4 |
Martin Pitt (pitti) wrote : | #5 |
Thanks, Till! I agree that under the current conditions returning to pdftops from poppler is reasonable.
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #6 |
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 "%%PageBounding
Till Kamppeter (till-kamppeter) wrote : | #7 |
- improved debdiff to add the needed functionality to Poppler Edit (5.2 KiB, text/plain)
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.
In freedesktop.org Bugzilla #19777, Albert Astals Cid (aacid) wrote : | #8 |
should -origpagesizes conflict with -paper, -paperw, -paperh?
Could you also add the switch to the man page?
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #9 |
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/
In freedesktop.org Bugzilla #19777, Albert Astals Cid (aacid) wrote : | #10 |
hmmm, yeah, no idea what this could mean, leave like it is for now.
Well, what about adding the documentation to the man page?
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #11 |
Created an attachment (id=26408)
Patch for the pdftops man page
Here we go: The patch for the updated man page of pdftops.
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #12 |
Created an attachment (id=26409)
Complete updated man page of pdftops
This is the complete updated man page of pdftops.
Till Kamppeter (till-kamppeter) wrote : | #13 |
This fixes also bug 372166.
In freedesktop.org Bugzilla #19777, Albert Astals Cid (aacid) wrote : | #14 |
Commited to master
Till Kamppeter (till-kamppeter) wrote : | #15 |
- Updated debdiff to cover bug 335397 Edit (6.3 KiB, text/plain)
Added the fix for bug 335397 to the debdiff. This bug also needs to be fixed to avoid a regression.
Launchpad Janitor (janitor) wrote : | #16 |
This bug was fixed in the package poppler - 0.11.0-0ubuntu3
---------------
poppler (0.11.0-0ubuntu3) karmic; urgency=low
* debian/
Fixed bug in copying ASCII85-encoded binary data from the PDF input
file which produced broken PostScript (LP: #335397).
* debian/
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
Changed in poppler (Ubuntu): | |
status: | Triaged → Fix Released |
Till Kamppeter (till-kamppeter) wrote : | #17 |
This fixes also bug 375763.
Changed in poppler: | |
status: | Confirmed → Fix Released |
Till Kamppeter (till-kamppeter) wrote : | #18 |
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.
Changed in cups (Ubuntu): | |
status: | Triaged → Fix Committed |
Till Kamppeter (till-kamppeter) wrote : | #19 |
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:/
To install the attached filter on your system, download the file and replace your /usr/lib/
sudo chmod 755 /usr/lib/
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) wrote : | #20 |
- Poppler-based pdftops CUPS filter Edit (6.5 KiB, text/plain)
Sorry, attached the wrong file. Here is the correct one:
Launchpad Janitor (janitor) wrote : | #21 |
This bug was fixed in the package cups - 1.3.10-3
---------------
cups (1.3.10-3) unstable; urgency=low
[ Till Kamppeter ]
* debian/
/usr/
by dpkg.
* debian/
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/
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/
(like 1200x600 dpi), as it leads to problems with images in some cases.
See http://
* debian/
debian/
loop which occured for some PDF files (LP: #382880).
* debian/
and ImageableArea entries in the PPD have no translation strings. Thanks
to Koji Otani to find the bug.
* debian/
debian/
debian/
debian/
debian/
Added pdftoopvp CUPS filter as part of the PDF filter add-on.
* debian/
be installed as part of the cups package
* debian/control: Added build dependencies needed by pdftoopvp: liblcms1-dev,
libfreetype
* 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/
PPDs of already existing print queues.
[ Martin Pitt ]
* Add gnutls-
libgnutls-
* 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:/...
Changed in cups (Ubuntu): | |
status: | Fix Committed → Fix Released |
DFreeze (dfreeze) wrote : | #22 |
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) wrote : | #23 |
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) wrote : | #24 |
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) wrote : | #25 |
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) wrote : | #26 |
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) wrote : | #27 |
- Example_printwcups.pdf Edit (94.7 KiB, application/pdf)
While I'd love to report that all is well (see: https:/
Attached are three test files of an svg drawing with text:
1. Example_
2. Example_
3. Example_
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.
NoOp (glgxg) wrote : | #28 |
NoOp (glgxg) wrote : | #29 |
Till Kamppeter (till-kamppeter) wrote : | #30 |
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) wrote : | #31 |
- Example_testfile.svg Edit (91.2 KiB, image/svg+xml)
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) wrote : | #32 |
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) wrote : | #33 |
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) wrote : | #34 |
- Print_Example_testfile.pdf Edit (23.2 KiB, application/pdf)
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_
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) wrote : | #35 |
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) wrote : | #36 |
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) wrote : | #37 |
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) wrote : | #38 |
Excellent! Is there a way that this can be enabled in jaunty proposed for testing?
Till Kamppeter (till-kamppeter) wrote : | #39 |
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 ...
Changed in cups (Ubuntu Jaunty): | |
importance: | Undecided → High |
status: | New → Fix Committed |
Changed in poppler (Ubuntu Jaunty): | |
importance: | Undecided → High |
status: | New → Fix Committed |
Till Kamppeter (till-kamppeter) wrote : | #40 |
Till Kamppeter (till-kamppeter) wrote : | #41 |
Martin Pitt (pitti) wrote : | #42 |
Accepted poppler into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
tags: | added: verification-needed |
Martin Pitt (pitti) wrote : | #43 |
Accepted cups into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
Till Kamppeter (till-kamppeter) wrote : | #44 |
Please note that to fix this problem BOTH packages (cups, poppler) from jaunty-proposed are needed. So please install both packages and check whether you can print everything without problems. Tell us your results here, both positive and negative feedback.
Martin Pitt (pitti) wrote : Re: [Bug 382379] Re: pdftops CUPS filter has several problems | #45 |
Till Kamppeter [2009-06-18 9:50 -0000]:
> Please note that to fix this problem BOTH packages (cups, poppler) from
> jaunty-proposed are needed. So please install both packages and check
> whether you can print everything without problems. Tell us your results
> here, both positive and negative feedback.
For the record, the updated cups has a versioned dependency on the new
poppler-utils, so it shouldn't be possible to upgrade cups and not
poppler-utils.
Benjamin Drung (bdrung) wrote : | #46 |
There is an regression: I printed a PDF two-sided (duplex) with two pages per side. The PDF with 3 pages should printed on one paper, but instead the back side of the paper stayed white and the page 3 is printed on a second page. The printer pulled the paper back like it does it when it prints in duplex.
Till Kamppeter (till-kamppeter) wrote : | #47 |
Benjamin Drung, can you please provide an error_log as described in the "CUPS error_log" section of https:/
Can you also tell us from which applications you tried to print, attach a sample input file.
Please also tell us which printer and which driver you are using.
Lennart Jütte (accounts-rtjuette) wrote : | #48 |
- cupy error log Edit (491.5 KiB, text/plain)
I'm running Jaunty and already added the proposed repository. A Kyocera Mita FS-1030D is attached to the system.
Before adding the new repo everything printed out fine from a Windows Vista machine printing over samba. My MacBook running OS X 10.5 and cups 1.3.10 needed a few minutes per page that contained graphics.
After updating (i think cups and poppler were updated) everything prints fast, but i can't print two sided documents from my MacBook. The problem:
Usually my printer prints on the first side, then pulls the sheet back in and prints the second side. Now it pulls the sheet back in but leaves the second page empty. The second page is printed on another sheet. Same procedure here, only one side gets in touch with some toner.
The Windows machine prints fine... grrr!
Additionally the background (light blue) on the Mac-printout was messed up. It consisted of little grey boxes. I'll try to attach some pictures.
The error log contains the output for the printout of the slides and a printout of https:/
Lennart Jütte (accounts-rtjuette) wrote : | #49 |
Lennart Jütte (accounts-rtjuette) wrote : | #50 |
Lennart Jütte (accounts-rtjuette) wrote : | #51 |
Lennart Jütte (accounts-rtjuette) wrote : | #52 |
I just noticed, that the background on the print done from Windows looks strange, too.
Till Kamppeter (till-kamppeter) wrote : | #53 |
Duplex problem is mainly that the "sides=..." option supplied to CUPS does not get picked up. But this is not a pdftops problem where this bug is about. padtops was never resonsible to pick up the "sides=..." option. So the duplexz should have probably already failed with the old Ghostscript-based pdftops filter.
The background of the document is a really bad design which shouts for interferences both on the screen and on the printout. The blue background is a very fine blue and white chessboard structure and the yellow background are as fine little yellow squares on white. If you display the original file on the screen you see already the ugly interferences and every time new ones if you zoom into the document. The actual square patterns you will see with gv (install it from Universe). Open the original PDF with gv and then drag a small square with the middle mouse button and after that choose 64 in the menu, for 64 times magnification. Do this operation again in the magnified view to get 64*64 times magnification. Then you see the squares.
This structure stays perfectly conserved, when you turn the PDF into PostScript with Poppler
pdftops 00\ -\ Ziele_Inhalt_
and this PostScript goes to the printer, causing a new interference, different to the ones which you have seen on the screen. I have done also a quick test with Ghostscript (much slower):
pdf2ps 00\ -\ Ziele_Inhalt_
and the background is also perfectly conserved. So I can expect interferences on my printout, too. Perhaps the old Ghostscript-based pdftops turned everything into raster graphics and so blurred the background somehow and this way made this file print more nicely.
Unfortunately, we cannot accept a filter working this way, as otherwise users of print-into-PDF(SVG, PS)-file printers or users of large-format printers (sending A4 pages with the "fitplot" option) will complain.
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #54 |
Unfortunately, my first patch was not perfect. It correctly switches paper sizes so that the printer switches trays, but because I am setting the page size in every page header, in every page header the duplex gets reset to the front side of the sheet, which makes the back sides never being used. So all jobs come out one-sided. The attached patch replaces my first one and fixes the problem. It simply compares the size of the current page with the size of the previous page and only adds a page size request when the page size changes.
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #55 |
Created an attachment (id=27012)
Fixed patch to add support for multiple page size output
In freedesktop.org Bugzilla #19777, Albert Astals Cid (aacid) wrote : | #56 |
Commited
Till Kamppeter (till-kamppeter) wrote : | #57 |
The problem is in Poppler. The fix I have done in Poppler to allow documents with pages of different sizes sets the page size in each page header. Setting the page size resets the duplex to print on the front side and so it gets never printed on back sides. I have fixed this by checking whether the current page size is different to the size of the previous page and only add a page size request to pages with a new size now.
Changed in poppler (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in poppler (Ubuntu Jaunty): | |
status: | Fix Committed → Triaged |
Till Kamppeter (till-kamppeter) wrote : | #58 |
Jesse (sbjesse) wrote : | #59 |
@till has this fix been uploaded to 'proposed' channel yet?
Till Kamppeter (till-kamppeter) wrote : | #60 |
Not yet. I am uploading a debdiff for it now. The Upload to -proposed will be announced here.
Till Kamppeter (till-kamppeter) wrote : | #61 |
- debdiff for the new poppler package for jaunty-proposed, based on the current one Edit (4.3 KiB, text/plain)
Till Kamppeter (till-kamppeter) wrote : | #62 |
Launchpad Janitor (janitor) wrote : | #63 |
This bug was fixed in the package poppler - 0.11.0-0ubuntu4
---------------
poppler (0.11.0-0ubuntu4) karmic; urgency=low
* debian/
page-
(LP: #382379).
-- Till Kamppeter <email address hidden> Mon, 22 Jun 2009 16:43:49 +0200
Changed in poppler (Ubuntu): | |
status: | Triaged → Fix Released |
Martin Pitt (pitti) wrote : | #64 |
Accepted poppler into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
Changed in poppler (Ubuntu Jaunty): | |
status: | Triaged → Fix Committed |
Ryan (rvanderbijl) wrote : Re: [Bug 382379] Re: pdftops CUPS filter has several problems | #65 |
Just wanted to confirm that this fixes my problem of the PDFs not
being searchable.
Thanks!
Benjamin Drung (bdrung) wrote : | #66 |
cups 1.3.9-17ubuntu3.2 with poppler 0.10.5-1ubuntu2.2 works for me. The PDFs are now printed correctly in duplex and the font do not have spurious lines. Printing pictures with eog works, too (after upgrading the RAM of the printer).
Till Kamppeter (till-kamppeter) wrote : | #67 |
Thanks Ryan and Benjamin, seems that all is doing OK now.
tags: |
added: verification-done removed: verification-needed |
Lennart Jütte (accounts-rtjuette) wrote : | #68 |
Confirmation:
I just printed Professor Gemminger's slides (see attachments) from Mac OS X 10.5.7. Settings: 2 slides per side, duplex. I had to wait a few seconds (maybe less than 10?) per sheet, but it works quite fast.
About the funny background: I zoomed in and saw the strange pattern the author used. This explains a lot.
Anoop (dr-adshah) wrote : | #69 |
Thank you, this seems to work perfectly now. Previously printing was very slow and some characters had black bars above them (Jaunty Jackalope printing to HP laserjet 2250).
mogliii (mogliii) wrote : | #70 |
- pdf-printing.tif Edit (79.2 KiB, image/tiff)
Hi,
my report here applies for Ubuntu Jaunty with HP Laserjet 4050 over JetDirect (Network). I have the latest packages installed, as explained in this thread:
dpkg -l cups
cups 1.3.9-17ubuntu3.2 Common UNIX Printing System(tm) - server
dpkg -l poppler-utils
poppler-utils 0.10.5-1ubuntu2.2 PDF utilitites (based on libpoppler)
Following problems:
(1) When I print something, lets assume only text from openoffice, it gets printed fine, but a message appears on the printer's display: "40 EIO 1 FEHLERH UBERTRAGUNG" (I have german printer). I found Bug No 229981 that seems to be similar.
(2) I printed the content of a website to .pdf (http://
(3) I printed the content of the website directly to the 4050 printer, went much faster and the fonts are properly printed. (no 40 EIO error)
I still feel that the whole printing thing needs some tweaking. I can not rely on my Ubuntu to print a scanned A4 page or a 80 page pdf document. However I can with WinXP. I hope this will be fixed.
Till Kamppeter (till-kamppeter) wrote : | #71 |
(1) (and also bug 229981) seems to be a bug in HP's PostScript interpreters. It did not occur with my printers (HP LaserJet 3390, P3005, Color LaserJet CM3530 MFP, probably they are too new). As long as the printouts come out correctly, simply ignore it.
For (2) not the CUPS package is the culprit but the cups-pdf package which makes CUPS performing unneeded filter detours. See bug 385709. This I have fixed in Karmic.
(3) shows that the original issue for which this bug was opened is fixed for you.
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)?
Launchpad Janitor (janitor) wrote : | #72 |
This bug was fixed in the package poppler - 0.10.5-1ubuntu2.2
---------------
poppler (0.10.5-1ubuntu2.2) jaunty-proposed; urgency=low
* debian/
page-
(LP: #382379).
-- Till Kamppeter <email address hidden> Mon, 22 Jun 2009 16:43:49 +0200
Changed in poppler (Ubuntu Jaunty): | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #73 |
This bug was fixed in the package cups - 1.3.9-17ubuntu3.2
---------------
cups (1.3.9-17ubuntu3.2) jaunty-proposed; urgency=low
[ Till Kamppeter ]
* debian/rules: Switch the pdftops filter back to Poppler, as Ghostscript
has a lot of problems in generating PostScript (LP: #382379).
* debian/
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).
[ Martin Pitt ]
* debian/control: Bump poppler-utils dependency to the version which
provides -origpagesizes.
-- Till Kamppeter <email address hidden> Thu, 18 Jun 2009 09:52:48 +0200
Changed in cups (Ubuntu Jaunty): | |
status: | Fix Committed → Fix Released |
Lennart Jütte (accounts-rtjuette) wrote : | #74 |
> 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) wrote : | #75 |
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:/
Lennart Jütte (accounts-rtjuette) wrote : | #76 |
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) wrote : | #77 |
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) wrote : | #78 |
- baranyai.ps Edit (96.3 KiB, application/postscript)
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) wrote : | #79 |
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) wrote : | #80 |
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) wrote : | #81 |
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) wrote : | #82 |
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:/
Jesse (sbjesse) wrote : | #83 |
Jesse (sbjesse) wrote : | #84 |
Jesse (sbjesse) wrote : | #85 |
my amateur eyes spot this spooky line in the log:
D [10/Jul/
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) wrote : | #86 |
Jesse, can you check (and attach) the following files:
/etc/cups/
/etc/cups/lpoptions
~/.cups/lpoptions
The first file will contain default settings if you change the "Job Options" in system-
Jesse (sbjesse) wrote : | #87 |
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=
Dest PDF PageSize=A4 Resolution=300dpi collate=false outputorder=normal number-up=2 wrap=false position=center fitplot=true
Till Kamppeter (till-kamppeter) wrote : | #88 |
AFAIK KDE apps save printer settings in ~/.cups/lpoptions.
Daniel (damendieta) wrote : | #89 |
I can't download (even see) the file.
Can you please give some more information about the install process?
Thanks
Till Kamppeter (till-kamppeter) wrote : | #90 |
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) wrote : | #91 |
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://
http://
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) wrote : | #92 |
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.
Changed in poppler: | |
importance: | Unknown → Medium |
In freedesktop.org Bugzilla #19777, Till Kamppeter (till-kamppeter) wrote : | #109 |
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://
Thanks in advance.
In freedesktop.org Bugzilla #19777, Adrian Johnson (ajohnson-redneon) wrote : | #110 |
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://
Changed in poppler: | |
importance: | Medium → Unknown |
status: | Fix Released → Confirmed |
Changed in poppler: | |
importance: | Unknown → Medium |
zcat (zcat) wrote : | #93 |
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) wrote : | #94 |
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) wrote : | #95 |
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) wrote : | #96 |
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://
GT (gleppert) wrote : | #97 |
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) wrote : | #98 |
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://
> 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://
Till, will any of this be backported to Maverick & Natty?
Till Kamppeter (till-kamppeter) wrote : | #99 |
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) wrote : | #100 |
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) wrote : | #101 |
For the problem of comment #78, we work on it in bug 780935.
Leo (leorolla) wrote : | #102 |
- printed this lanuchpad page using cups-pdf printer Edit (364.5 KiB, application/pdf)
This problem is back in Oneiric.
Leo (leorolla) wrote : | #103 |
- 235_package___Ubuntu.pdf Edit (329.4 KiB, application/pdf)
Till, NoOp, others,
Is there a workaround for this?
The solution in
https:/
didn't work, see file attached.
Bug Reporter 11 (bugreporter11) wrote : | #105 |
This bug is being proposed as the problem related to this questsion: http://
Peter Hedlund (peter-peterandlinda) wrote : | #106 |
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) wrote : | #107 |
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?
In freedesktop.org Bugzilla #19777, Martin Wildam (mwildam) wrote : | #108 |
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) wrote : | #111 |
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) wrote : | #112 |
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.
In freedesktop.org Bugzilla #19777, Gitlab-migration (gitlab-migration) wrote : | #113 |
-- 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:/
Changed in poppler: | |
status: | Confirmed → Unknown |
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.