| Summary: | printing does not work (with solution) | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Nick Warne <nick> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
There is no kdeprint in KDE 4.0, the problem is Okular-specific. (... and give a better title.) It isn't... it is all KDE applications.
Here is output of Konqueror:
Date: Fri, 25 Jan 2008 11:54:26 GMT")("cache-creation-date", "1201261573")("charset", "utf-8")("expire-date", "2147368447")("modified", "Sat, 21 Apr 2007 01:08:10 GMT")("referrer", "http://www.google.co.uk/")("request-id", "")("ssl_in_use", "FALSE"))
newly arrived metadata is QMap(("cache-creation-date", "1201261573")("expire-date", "2147368447")("modified", "Sat, 21 Apr 2007 01:08:10 GMT")("referrer", "http://www.google.co.uk/")("request-id", ""))
konqueror(13239)/khtml KHTMLView::print: printing: physical page width = 689 height = 987
konqueror(13239)/khtml (render) khtml::RenderCanvas::viewRect: viewRect: QRect(0,0 689x857)
konqueror(13239)/khtml (render) khtml::RenderCanvas::viewRect: viewRect: QRect(0,0 689x857)
konqueror(13239)/khtml KHTMLView::print: printing: html page width = 689 height = 857
konqueror(13239)/khtml KHTMLView::print: printing: margins left = 16 top = 16
konqueror(13239)/khtml KHTMLView::print: printing: paper width = 689 height = 987
konqueror(13239)/khtml KHTMLView::print: printing: scaled html width = 689 height = 966
konqueror(13239)/khtml KHTMLView::print: printed: page 1 bottom At = 966
lpr: Illegal option 'o'
Again, using lpr-cups it works fine.
and kate...
kate(13395)/kio (KDirListerCache) KDirListerCache::slotResult: finished listing KUrl("file:///home/nick")
kate(13395)/kio (KDirLister) KDirLister::stop:
kate(13395)/kio (KDirLister) KDirLister::stop:
kate(13395)/kio (KDirListerCache) KDirListerCache::forgetDirs: KDirLister(0x8468778) item moved into cache: KUrl("file:///home/nick")
kate(13395) KateRendererConfig::setSchemaInternal: Loading template colors 0x8543958
lpr: Illegal option 'o'
Nick
> lpr: Illegal option 'o'
True, but there is subtile difference: while konqueror and kate print by painting on the Qt print device, okular has to detect and send manually the postscript to lpr/lpr-cups/what else.
So, in the first case it looks like a Qt problem, while in case of okular it's an okular's issue.
OK, but I am reporting ALL KDE apps fail to print unless lpr is a symlink to lpr-cups or the actual binary to lpr-cups (or variations thereof). It all works perfectly with cups lpr. This is _not_ okular specific. I don't run a lpd server - so lpr never works. But I use cups... Nick I found out that when Okular addresses lpr the actual ps script file isn't created... there is no such file as okularA22566.ps in my tmp folder...
The output when i command Okular to print a pdf:
okular(22566)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr" with arguments ("-P", "deskjet-3600", "-#1", "-J", "Examenrooster juni.pdf", "-o", "media=A4", "-o", "landscape", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=False", "-r", "/tmp/kde-samme/okularA22566.ps")
@Samme:
the file actually exists until the print job is ended.
See lpr --help:
-r
Specifies that the named print files should be deleted after printing them.
Of course, this works only with CUPS' lpr.
SVN commit 816881 by jlayt: Some distros rename the CUPS version of lpr as lpr-cups or lpr.cups . When detecting which exe to use, check for these first. CCBUG: 156639 This should be backported to 4.0, but I don't have a checkout of that. M +18 -11 fileprinter.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=816881 SVN commit 816889 by pino: Backport SVN commit 816881 by jlayt: Some distros rename the CUPS version of lpr as lpr-cups or lpr.cups . When detecting which exe to use, check for these first. CCBUG: 156639 M +18 -11 fileprinter.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=816889 Above commit should resolve this for okular, I've tested this using a symlink for lpr-cups, so it should be OK. Error message "lpr: Illegal option 'o'" means that the 'normal' lpr dosn't take -o at all, that's a Cups only addition. I don't know why the other KDE apps are showing the same issue, as Qt4 AFAIK now talks directly to Cups when using Cups (since at least 4.3), rather than cheating by using lpr as they did in the Qt3 series. If this is still an issue for you, you will need to report the bug to Trolltech. I'd suggest testing using a Qt only app, like the Qt4 Assistant, just to confirm. Thanks! My Okular (most recent 4.1rc1+ from Debian experimental) also fails to print. I have no lpr-cups or such, just lpr and lprm which I assume are cups versions. I had problems in the past using lpr commands from programs. Usually, (the old) kprinter (which still) works. I have acroread using that. Okular has no option and kprinter is from 3.5. One for reason that 4 needs a call compatable decop stand-in since the old apps are still going to be around! |
Version: (using 4.00.80 (KDE 4.0.80 >= 20080104), compiled sources) Compiler: gcc OS: Linux (i686) release 2.6.24-rc8-gd8c89eb3 Basically, this is a heads-up on this issue I found. CUPS 1.2.2 LPRng 3.8.32 Not one of my KDE applications would print - all goes through the motions, but no output. Using other apps (GTK etc.) worked, and CUPS test page from server works OK et al. After investigation, it appears there is an issue with 'lpr'. Both LPRng and CUPS produce a binary called 'lpr'. Usually the distro renames CUPS 'lpr' to 'lpr.cups', or 'lpr-cups' (or similar). Also, some rename both (lpr-lprng etc.). I found that I have LPRng 'lpr' and 'lpr-cups'. Now, KDE print uses 'lpr'. And on my system, with Samsung 1610 printer, this produces an error so nothing gets printed: okular(10691)/okular (app) Okular::DocumentPrivate::sendGeneratorRequest: sending request id=4 78x101@0 async == false okular(10691)/okular (app) Okular::Document::requestPixmaps: request id=3 459x594@0 okular(10691)/okular (app) Okular::DocumentPrivate::sendGeneratorRequest: sending request id=3 459x594@0 async == false okular(10691)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr" with arguments ("-P", "samsung", "-#1", "-J", "water.pdf", "-o", "media=A4", "-o", "portrait", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=False", "-r", "/tmp/kde-nick/okularQ10691.ps") lpr: Illegal option 'o' ... dumps lpr options here and stops. I don't know why LPRng 'lpr' produces that error, but reading up it looks like one of the '-o options' is not recognised/illegal for my printer. BUT! changing to use the CUPS 'lpr' (symlink lpr -> lpr-cups, or a straight replacement with CUPS lpr in /usr/bin/ ) all prints and works wonderfully. This is bit of a mess. Nick