Bug 156639 - printing does not work (with solution)
Summary: printing does not work (with solution)
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-25 12:39 UTC by Nick Warne
Modified: 2008-07-19 22:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Warne 2008-01-25 12:39:50 UTC
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
Comment 1 Pino Toscano 2008-01-25 12:50:29 UTC
There is no kdeprint in KDE 4.0, the problem is Okular-specific.
Comment 2 Pino Toscano 2008-01-25 12:51:10 UTC
(... and give a better title.)
Comment 3 Nick Warne 2008-01-25 13:01:30 UTC
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
Comment 4 Pino Toscano 2008-01-25 13:08:25 UTC
> 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.
Comment 5 Nick Warne 2008-01-25 17:58:20 UTC
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
Comment 6 Samme Vreysen 2008-05-20 14:32:25 UTC
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")
Comment 7 Pino Toscano 2008-05-20 14:42:08 UTC
@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.
Comment 8 John Layt 2008-06-04 23:29:17 UTC
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
Comment 9 Pino Toscano 2008-06-04 23:47:25 UTC
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
Comment 10 John Layt 2008-06-04 23:56:54 UTC
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!
Comment 11 David Baron 2008-07-19 22:58:05 UTC
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!