Summary: | net-print/cups can't print PDF files directly | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bruce Guenter <bruce> |
Component: | [OLD] Printing | Assignee: | Printing Team <printing> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aeriksson, ame_24, armin76, bowlin, daniel.deptula, danila.bespalov, dario.fabiani, dave, EoD, hyedad, jarausch, jesse, joe, jordi.bofill, kfm, kwilson, marko.steinberger, mlspamcb, njsg, peter, pfrank, ryoichiro.suzuki, tech31842 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch to fix cups-1.3.11-r1.ebuild so the CUPS pdftops filter is built.
makes configure script accept a path for pdftofs |
Description
Bruce Guenter
2010-03-17 05:24:24 UTC
Me too. This was also a problem for me after installing an updated net-print/cups-1.3.11-r1. Doing as Bruce suggested (copying /usr/portage/net-print/cups/files/pdftops-1.20.gentoo to /usr/libexec/cups/filter/pdftops and restarting cups (/etc/init.d/cups restart) seemed to have done it. Thanks Bruce! Upgrading to 1.4.2 and 1.4.3 worked for me. Cups SHOULD print PDF's it's hardcoded by default. for some reason the configure step (which has --enable-pdftops and --with-pdftops=/usr/bin/pdftops ) defined goes wrong. (bug in configure) that's why the pdftops filter isn't created and that again is the reason why pdf doesn't print. See also bug: 306229 (enhancement request for this) Hand modifying the config.h & make pdftops does generate the filter... Maybe installing the new cups is the best answer to this, should the tree be updated? I tried upgrading... no luck. The new code still has trouble. pdftops is supplied, but pstops fails. upgrading hplip & ghostscript didn't exactly help either. hplip crashes with double free errors. Installing the current version with handcompiled pdftops seems to do best: replace /* #undef HAVE_PDFTOPS */ #define CUPS_PDFTOPS "" with #define HAVE_PDFTOPS 1 #define CUPS_PDFTOPS "/usr/bin/pdftops" I think that the cups configure script don't support the --with-pdftops=path syntax (that is used in cups-1.3.11-r2.ebuild) before cups 1.4: In 1.3.11 source: $ ./configure --with-pdftops=/usr/bin/pdftops --enable-pdftops $ grep -i pdf config.log $ ./configure --with-pdftops=/usr/bin/pdftops --enable-pdftops CUPS_PDFTOPS='' PDFTOPS='' pdfdir='${docdir}' #define CUPS_PDFTOPS "" PDFTOPS='' pdfdir='${docdir}' #define CUPS_PDFTOPS "" But if I try: $ ./configure --with-pdftops=pdftops --enable-pdftops $ grep -i pdf config.log $ ./configure --with-pdftops=pdftops --enable-pdftops configure:18822: checking for pdftops configure:18840: found /usr/bin/pdftops configure:18852: result: /usr/bin/pdftops ac_cv_path_CUPS_PDFTOPS=/usr/bin/pdftops CUPS_PDFTOPS='/usr/bin/pdftops' PDFTOPS='pdftops' pdfdir='${docdir}' #define HAVE_PDFTOPS 1 #define CUPS_PDFTOPS "/usr/bin/pdftops" also, ./configure --help says: --with-pdftops set pdftops filter (gs,pdftops,none), default=pdftops in cups 1.3.11, but says: --with-pdftops set pdftops filter (gs,/path/to/gs,pdftops,/path/to/pdftops,none), default=pdftops in cups 1.4.3 I can confirm this bug with 1.3.11-r1. Upgrading to 1.4.3 solves the problem for me. (In reply to comment #5) > I think that the cups configure script don't support the --with-pdftops=path > syntax (that is used in cups-1.3.11-r2.ebuild) before cups 1.4 My system is amd64. I can confirm Dario's finding; /usr/libexec/cups/filter/pdftops is not being generated. As Dario proposed, I patched cups-1.3.11-r1.ebuild in my local portage tree and re-emerged cups-1.3.11-r1. Now printing of PDF files works again. Previously, I got the error message: $ lp testfile.pdf lp: Unsupported format 'application/pdf'! Next I'll attach a very simple patch file for cups-1.3.11-r1.ebuild. Not sure if this will help the Gentoo cups maintainer or anyone else, but I hope it will. Clemmitt Created attachment 232629 [details, diff]
Patch to fix cups-1.3.11-r1.ebuild so the CUPS pdftops filter is built.
A simple patch created to keep printing of PDF files via the "lp" command from failing with the error message, "lp: Unsupported format 'application/pdf'!"
I can confirm that the patch from Clemmitt M. Sigler works just fine on my sparc server! This should probably be added to the tree, as this is really annoying to have a cups server which is not able to print pdf files... same problem here. The patch works here too: http://bugs.gentoo.org/attachment.cgi?id=232629&action=view I wonder why does kwrite (kde 4.4.4) send application/pdf and not application/postscript? (In reply to comment #8) > Created an attachment (id=232629) [details] I can confirm that this patch works. Any idea when this will be propagated to the tree ? My newly (gentoo-stable) system did not print from KDE, but from Mozilla and command line (lp command). 1. I had to find out that KDE sends PDFs to cups. 2. It took me a while to find this item. Please update this ebuild in the portage tree or stablize the cups-1.4 line. Not being able to print from any KDE application is a no-go. regards Created attachment 243289 [details, diff] makes configure script accept a path for pdftofs As Dario said in comment #5, the cups configure script doesn't support the --with-pdftops=/some/path syntax. I created a patch which makes the build system accept it. This patch should be applied in src_prepare(). I think Clemitt's patch isn't acceptable because it does NOT work if app-text/poppler isn't already installed; it was moved to PDEPEND to avoid cyclic dependencies. With my solution the pdftops path override works. The stable cups ebuilds have been broken for too long, please update the portage tree really soon with this fix (or make a similar, better patch if you know autotools better than me). Wait a minute, I think this is natural that cups package don't include pdf support and I think this is wrong to create/force pdf support when compiling cups, because there is a package called net-print/cups-pdf which do the trick. So install this package, restart cups and you will be able to print PDF files. Abyss: net-print/cups-pdf is a package to have a "print to PDF-File" capability added to cups. This issue is about the capability of native cups to convert either pdf or postscript to any printer format used by a physical printer. The ebuild needs to be changed because the .configure script of cups was changes. So yes it needs to be solved, and no cups-pdf is not a solution. This is a regression. It should be fixed. The lpr program used to be able to print pdf files. I've written programs that depend upon this functionality of lpr. The cups-pdf package does something completely different: $ eix cups-pdf * net-print/cups-pdf Available versions: 2.4.2 ~2.4.5 2.4.8 ~2.5.0-r1 Homepage: http://www.cups-pdf.de/ Description: Provides a virtual printer for CUPS to produce PDF files. ^^^^^^^^^^^^^^^^^ When will the ("stable!") ebuild in portage be fixed? I've reproduced this bug with net-print/cups-1.3.11-r2 on x86. I agree that this is a regression that should be fixed, because many people depend on lpr's ability to print pdfs. This is nuts. Chrome is completely unable to print now that application/pdf is unsupported by the Gentoo build of cups. Come on, let's get this bug fixed! Thx to this bug report I finally can print again with KDE apps :-) I can confirm upgrading to cups-1.4.4-r2 solved the issue for me. I tried upgrading to cups-1.4.4-r2 but was no longer able to print. There seems to be multiple problems with the newer cups: http://bugs.gentoo.org/show_bug.cgi?id=285159 https://bugs.launchpad.net/ubuntu/+source/cups/+bug/420015 Upgrading didn't work for me, either, on one of my machines. I was unable to make my usb printer work with net-print/cups-1.4.4-r2. The OP's suggestion: $ cp /usr/portage/net-print/cups/files/pdftops-1.20.gentoo /usr/libexec/cups/filter/pdftops $ chmod +x /usr/libexec/cups/filter/pdftops works for me on every machine I maintain. This seems like a very simple thing to patch in; is there a reason the ebuild in the tree hasn't been updated? (In reply to comment #21) > > $ cp /usr/portage/net-print/cups/files/pdftops-1.20.gentoo > /usr/libexec/cups/filter/pdftops > $ chmod +x /usr/libexec/cups/filter/pdftops This worked here too (after restarting cupsd). Thanks. (In reply to comment #21) > Upgrading didn't work for me, either, on one of my machines. I was unable to > make my usb printer work with net-print/cups-1.4.4-r2. > > The OP's suggestion: > > $ cp /usr/portage/net-print/cups/files/pdftops-1.20.gentoo > /usr/libexec/cups/filter/pdftops > $ chmod +x /usr/libexec/cups/filter/pdftops > > works for me on every machine I maintain. This seems like a very simple thing > to patch in; is there a reason the ebuild in the tree hasn't been updated? > works for me too (thank you every so much!). i can confirm the same problem with net-print/cups-1.4.4-r2 on amd64 (In reply to comment #21) > Upgrading didn't work for me, either, on one of my machines. I was unable to > make my usb printer work with net-print/cups-1.4.4-r2. > > The OP's suggestion: > > $ cp /usr/portage/net-print/cups/files/pdftops-1.20.gentoo > /usr/libexec/cups/filter/pdftops > $ chmod +x /usr/libexec/cups/filter/pdftops This worked for me also. Installing an unstable ebuild just to fix this problem seems silly. I'm surprised this hasn't been fixed in stable... Fixed in -r3, thanks (In reply to comment #25) > Fixed in -r3, thanks > I don't see this as a solution at all. I avoid KEYWORDing packages as much as possible. My business depends on the stability of the system. So, I'm just now installing Gentoo on a new machine and cups-1.3.11 won't build because it can't find /usr/bin/pdftops. Just copying over the filter didn't help because the pdftops program is missing. It is apparently provided by poppler, which depends on cups. So, basically, you can't install cups because you can't install poppler because you can't install cups: Circular dependencies. I had to copy /usr/bin/pdftops from another machine. Regarding comment #26: ignoring the "my business" part of the complaint, (Gentoo is a unpaid volunteer effort and not an extension of any business) perhaps this should be reopened considering the technical aspect of the comment. -r3 might make new system builds with cups not so fun, no? Unless there's some way around the circular dependency, if that is indeed the case? *** Bug 336441 has been marked as a duplicate of this bug. *** (In reply to comment #26) > (In reply to comment #25) > > Fixed in -r3, thanks > > > I don't see this as a solution at all. I avoid KEYWORDing packages as much as > possible. My business depends on the stability of the system. So, I'm just now > installing Gentoo on a new machine and cups-1.3.11 won't build because it can't > find /usr/bin/pdftops. Just copying over the filter didn't help because the > pdftops program is missing. It is apparently provided by poppler, which depends > on cups. So, basically, you can't install cups because you can't install > poppler because you can't install cups: Circular dependencies. I had to copy > /usr/bin/pdftops from another machine. > This should happen on 1.4.4 as well, so please open a new bug if there isn't already |