After reinstalling net-print/cups-1.3.11-r1 after the March 8 2010 change to its pdftops handling, I am no longer able to directly print PDF files. lpr something.pdf reports: lpr: Unsupported format 'application/pdf'! I turned on "LogLevel debug2" in the cups configuration, and saw that the application/pdf to application/vnd.cups-postscript filter was not being read from the configuration. There are no other PDF related errors in the logs other than: add_printer_formats: lp: application/pdf not supported I observed from portage logs that an older installation of net-print/cups-1.3.11-r1 (same version) used to install /usr/libexec/cups/filter/pdftops but the current version does not. Installing /usr/portage/net-print/cups/files/pdftops-1.20.gentoo as /usr/libexec/cups/filter/pdftops makes it work again. I don't know if this is the correct solution. Reproducible: Always # emerge --info Portage 2.1.7.17 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r1, 2.6.32.8 x86_64) ================================================================= System uname: Linux-2.6.32.8-x86_64-Intel-R-_Pentium-R-_Dual_CPU_E2180_@_2.00GHz-with-gentoo-1.12.13 Timestamp of tree: Tue, 16 Mar 2010 12:00:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.4.6, 2.5.4-r4, 2.6.4-r1, 3.1.1-r1 dev-python/pycrypto: 2.1.0_beta1 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.6.3-r1, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.1.2, 4.2.4-r1, 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -pipe -mtune=core2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O3 -pipe -mtune=core2" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests buildpkg collision-protect distlocks fixpackages metadata-transfer news notitles parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1" LINGUAS="en en_CA en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages/lorien64" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/gnome /usr/portage/local/layman/hardened-development /usr/portage/local/layman/x11 /home/bruce/portage /home/bruce/FutureQuest/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="16bit 64bit 7zip X a52 aac abiword accessibility acl acpi adns aiglx alsa amd64 applet asf ass audio automount avi bash-completion bitmap-fonts bzip2 c++ cairo cdparanoia cdr chroot cleartype contrast corefonts cpdflib crypt cscope css ctype cups curl curlwrappers custom-optimization cxx d dbus dia dillo divx4linux djbfft djvu dri dvd dvdr dvdread dvi edl emacs enblend encode epiphany ethereal evo examples exceptions exif extrafilters extras fam fame ffmpeg filepicker fits flac fluidsynth font-server fontconfig foomaticdb fts3 gcj gif gimp gimpprint git glade glib glitz gnome gpg gphoto2 grammar gstreamer gtk gtk2 guile hal hdri hotpixels hpcups hpijs hunspell imap imlib imlib2 inherit-graph innodb ipv6 jack jadetex java java6 javascript jbig jikes jpeg jpeg2k justify kde ladcca ladspa lcms ldap lensfun libffi libnotify llvm lm_sensors lua lzma mad maildir math matroska mbox megaupload memlimit menubar midi mikmod mime mjpeg mmx mmxext mng modplug modules moznoirc moznomail mozp3p mozsvg mozxmlterm mp3 mp4 mpeg mplayer mudflap multilib musepack mysql ncurses networking nfs nls nptl nptlonly nsplugin ntfs ocaml ocamlopt ogg ogg123 oggvorbis openexr opengl openmp pam pango pcf pcre pda pdf pdflib perl plotutils png policykit posix postgres postgresql ppds python qmail qt3support qt4 quicktime rar raw readline regex samba sasl scanner schroedinger sdl seamonkey sendfile sensord session shared sharedmem sift slang smime smp soap sockets sourceview sox speex spell sqlite sqlite3 sse sse2 sse3 ssl ssse3 startup-notification static-analyzer subversion svg symlink t1lib tabs tcltk tcpd theora thesaurus threads threadsafe tiff truetype truetype-fonts type1 type1-fonts unicode usb utf8 utils uudeview v4l v4l2 valgrind video view-captcha vorbis wad webdav-neon webkit wma wmf wordperfect x264 xcb xchattext xine xml xml2 xorg xpdf-headers xpm xrandr xscreensaver xulrunner xv xvid xvmc zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authz_host dir mime" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_CA en_US" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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