Bug 183632 - Printing to printer doesn't work with LPR (except in Okular)
Summary: Printing to printer doesn't work with LPR (except in Okular)
Status: RESOLVED WORKSFORME
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: print-dialog (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2009-02-08 00:04 UTC by James Richard Tyrer
Modified: 2018-10-29 02:22 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Not a patch, but rather an experiment (401 bytes, text/plain)
2009-02-08 05:27 UTC, James Richard Tyrer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Richard Tyrer 2009-02-08 00:04:53 UTC
Version:            (using KDE 4.2.0)
Compiler:          GCC 4.3.2 
OS:                Linux
Installed from:    Compiled From Sources

I created a file in KWrite and tried to print it to the printer connected directly to my computer.  I am using LPR as the print spooler.

The KPrint dialog opens, "lp" is selected, I click the "Print" button and nothing happens.

So, I tried making a PDF which works.

I opened the PDF in Okular and I can print it there.

I suspect that the code in Okular that explicitly selects a print command needs to be in KDELibs.
Comment 1 Pino Toscano 2009-02-08 00:11:13 UTC
Qt offers the printing dialog and the actual printing, so Qt issue.
Comment 2 James Richard Tyrer 2009-02-08 01:04:25 UTC
This is not a Qt issue.  The problem will probably need to be fixed in:

KStandardAction::Print

so it would be a kdeui issue.
Comment 3 James Richard Tyrer 2009-02-08 05:27:59 UTC
Created attachment 31109 [details]
Not a patch, but rather an experiment

It is as I suspected.  It is necessary to set the print command.

Is this a bug in Qt, or is it supposed to work this way?

IIUC, it is necessary to set the command because it isn't always the same which means that rather than using the constant string, we would need to use this code in Okular:

        QString print_cmd = QChar::null;

        if ( !KStandardDirs::findExe("lpr-cups").isEmpty() ) {
            print_cmd = "lpr-cups";
        } else if ( !KStandardDirs::findExe("lpr.cups").isEmpty() ) {
            print_cmd = "lpr.cups";
        } else if ( !KStandardDirs::findExe("lpr").isEmpty() ) {
            print_cmd = "lpr";
        } else if ( !KStandardDirs::findExe("lp").isEmpty() ) {
            print_cmd = "lp";
        }

        printer.setPrintProgram ( &print_cmd );

Perhaps something should be added for the case where a command isn't found.
Comment 4 John Layt 2009-02-12 23:53:58 UTC
This is a Qt bug and should be reported there.  Quite where in the print stack needs to be narrowed down.

All the KStandardAction does is call the createPrintDialog method which returns a QPrintDialog.

All apps except Okular for PDF and Postscript formats after reading the settings from the dialog paint onto a QPrinter which then creates a print file and sends it to the printer system. Qt supports CUPS, and if CUPS is not found then it falls back to using lpr.  Qt also supports Win and Mac.

The fact you get a print dialog, are able to select a printer to print to, and in Okular get a successful print where other apps fail implies to me that there is an issue in the Qt lpr print file sub code that causes a non-fatal error.

So, first step, lets determine if Qt is reading your installed printers properly.  Please take a screenshot of the print dialog opened with the printer selection combo-box opened showing the available selection of printers and post it here.  Also post the output from running the commands 'lpq -a -l' and 'lpstat -l -t' and the contents of the /etc/printcap file.
Comment 5 Michael Weghorn 2018-01-16 16:26:29 UTC
This bug report is quite old.

@James Richard Tyrer: Is this still a problem nowadays?
Comment 6 Michael Weghorn 2018-05-10 19:18:48 UTC
(In reply to Michael Weghorn from comment #5)
> This bug report is quite old.
> 
> @James Richard Tyrer: Is this still a problem nowadays?

I'm changing the bug status to NEEDSINFO for now, since the questions has not been answered yet.
Comment 7 Andrew Crouthamel 2018-09-28 03:24:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Andrew Crouthamel 2018-10-29 02:22:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!