kde print ignores duplex & copy options

Bug #286014 reported by Benjamin Kay
168
This bug affects 22 people
Affects Status Importance Assigned to Milestone
qt4-x11 (Ubuntu)
Triaged
Medium
Unassigned
Declined for Intrepid by Harald Sitter

Bug Description

When printing in KDE 4 (Kubuntu 8.10 Intrepid Ibex Beta), print options like duplex and copy number are ignored. For example, if I try to print two copies of a two-page document from Okular with duplex enabled, I end up with only one copy and no duplex. Print options are also ignored by Konqueror and, I suspect, probably all KDE 4 applications. This is a regression from KDE 3 in Kubuntu 8.04 Hardy Heron. If this bug isn't unique to my printer, then it ought to be a release blocker unless it's impossibly difficult to fix.

I'm using system-config-printer-kde 0.11, KDE 4.1.2, from the Kubuntu 8.10 Beta CD on an x86_64 machine. The printer in question is a Brother HL-5250DN using the BR-Script3 PPD.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

First, this is not a bug in system-config-printer-kde. system-config-printer-kde only serves for setting up and modifying print queues. It does not provide the printing dialog for KDE applications nor any other functionality for printing jobs out of applications.

To check whether CUPS does not cause the problem by somehow not obeying the option settings I have sent a job as you like to have via the command line:

lpr -P duplexprinter -# 2 -o Collate -o page-ranges=1-2 -o Duplex=DuplexNoTumble atleasttwopages.pdf

This job came out correctly: Two copies in Duplex.

I have also tried to reproduce your problem with Okular, and I got indeed only one copy, but at least Duplex. So there must be a bug in Okular or in the KDE printing dialog. I assign the bug to kdebase as this package most probably provides KDE's printing dialog.

By the way, my printer is the HP LaserJet 3390, used with HPs PostScript PPD file as it is shipped with Ubuntu.

Revision history for this message
Benjamin Kay (benkay) wrote :

I tried your command line print and got four copies in duplex (obviously expecting only two copies). Thanks for reassigning the bug.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

I have found out this, too as I did the tests mentioned in my answer and immediately fixed the problem and reported a freeze exception request, bug #286048.

Revision history for this message
Benjamin Kay (benkay) wrote :

Thank you, Till. I tested the debdiff you posted in bug #286048, and it fixes the issue with lpr getting the copy number wrong. Duplex and copy number in KDE application (I retested with Okular) are still broken. I still think this bug ought to be fixed before Kubuntu 8.10 is released.

Revision history for this message
Benjamin Kay (benkay) wrote :

Although bug #286048 has been fixed, this bug is still manifest in the Kubuntu Intrepid release candidate.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Currently KDE apps use the Qt printing system since kdeprint hasn't been ported to KDE4, so assigning to the Qt4 package.

Revision history for this message
Yözen Hernández (yhernand) wrote :

I still experience this bug in Intrepid final using KDE 4.1.3 (but also experienced it in 4.1.2). It seems to go beyond duplex and copy number, as I just started a print job specifying only pages 3 - 4 in kate, and got all 4 pages instead. I've not tried this with other documents or KDE programs since I'd rather not waste any more paper.

Revision history for this message
RFigura (figura) wrote :

I have the same problem with my printer. I also have a 64 bit System. The command line print worked with 2 duplex printouts, but in Okular I cannot print in duplex.

Revision history for this message
Authority (8-launchpad-weshardin-com) wrote :

Just another me too, but I'm only testing copies, not duplex.

Kubuntu 8.10 on the client. Ubuntu 8.10 Server on the server. Both x86_64. Both up-to-date.

I confirmed that the CUPS server is only getting a request for 1 copy. From the CUPS error_log with debug level logging:

D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[0]="Msouth"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[1]="512"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[2]="whardin"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[3]="netapp_volumes.dvi"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[4]="1"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[5]="media=Letter sides=one-sided f
inishings=3 number-up=1 job-uuid=urn:uuid:7f37c6f6-6d2f-33be-69a0-67ddae2fdf37"
D [14/Jan/2009:13:51:34 -0600] [Job 512] argv[6]="/var/spool/cups/d00512-001"

argv[4] is the number of copies requested and it's always 1, no matter what I put in the Okular print dialog.

Revision history for this message
Pino Toscano (pinotree) wrote :

Okular cannot currently do anything to print more than one copy at a time when printing PDF, PS, DjVU, and DVI.
The reason is simple: the Qt printing system is "smart enough" to actually think that it can use CUPS "copies" feature, so it always exposed the information that only 1 copy is needed.
Given the inflexibility of the Qt printing system, we currently have to take the information from it, and invoke lp* manually. Thus, if you do 2+2 it can be understood that Okular always knows about 1 copy to provide.

Revision history for this message
robert leleu (robert-jean-leleu) wrote :

similar problem:

printing from A4 pdf "by two" to A3 sheet, I found that the "assembler" (french for assemble? join copies?) is inoperant.

If I print 2 copies, the 2 copies for a given sheet are printed successively...

Changed in qt4-x11 (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

For reference, the upstream ticket for this issue can be found here: http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=219318

Changed in qt4-x11 (Ubuntu):
status: Confirmed → Triaged
tags: added: regression-release
Revision history for this message
Sergio Callegari (callegar) wrote :

Please let me follow up with duplicate bug 328988, advocating again that until the print system in KDE 4 is in shape, a fallback should be provided.

This can be

1) kdeprint from kde 3.5.10 that is already packaged for ubuntu since there is a kubuntu jaunty derivative based on KDE 3.5
2) the print dialogue application from xubuntu
3) the gnome print dialog application

Where 1) appears to me as the most obvious choice. IMHO it is wrong to say that shipping kdeprint from KDE 3.5 would not help KDE 4 applications:

Case:
Mr. A wants to print only the odd pages of a document from a KDE 4 application (or multiple copies of the document, or an n-up doc). Using only KDE 4 apps, simply he cannot. Best option today: print to pdf and then do the real printing with the *non free* acrobat reader that has odd-even page selection. This is what I have seen all people doing.
With kdeprint from kde 3.5 one would be able to first print to pdf from the kde4 app and then simply print the pdf with kdeprint. No need to rely on non-free software anymore.

And of course kdeprint from 3.5.10 would help all those non-kde application that want to be provided a command for printing since kde 4 has nothing to offer here (think of emacs, tgif, CAD stuff, ecc.).

Revision history for this message
pureblood (freeseek) wrote :

I don't know what to think. I am using KDE 4.3.0 which I assume is based on QT 4.5 but the printing problem is still the same. When I try to print, the printer refuses to print because it was told to print on A4 even if US Letter is selected in the printing dialog. I understand that this is not a KDE issue, but if important bugs like this fail at getting fixed in a one year span, I start to be suspicious about the whole set of libraries KDE is based on.

Why did the people at QT insisted to make the printing dialog if it lacks features and is buggy?

Revision history for this message
lenooh (lenooh) wrote :

This bug is still present in Kubuntu 9.10 (KDE 4.3.2).

Trying to print 4 copies of 1 page PDF file, results in printing only 1 copy. I guess other options are ignored as well.

This is a very annoying and serious bug, at least for office use.

Revision history for this message
Sergei Ivanov (svivanov) wrote :

Have this bug on Kubuntu 9.10 with KDE 4.3.3 from PPA (okular never prints more than one copy). But kate and Konqueror *do* print several copies when asked to. It seems that on this system the bug is specific to okular.

Revision history for this message
Peter Lemieux (seijisensei) wrote :

Another vote for failure to print multiple copies from okular, this time on 9.04 (Jaunty). Only one copy gets printed no matter what value is specfied in the Options dialog.

Revision history for this message
Johannes (thc-gangsta) wrote :

same here with 9.10 32bit and 9.04 32 bit.

Revision history for this message
jonjermey (jonjermey-optusnet-deactivatedaccount) wrote :

Same here with Mint 8 printing from Okular over a network to a Brother laser printer: it 'prints' a blank first page then sucks it back in and prints the document on the reverse side, regardless of duplex settings. I also get the failure to print multiple copies.

Revision history for this message
Peter Lemieux (seijisensei) wrote :

Read the linked comments at http://bugreports.qt.nokia.com/browse/QTBUG-2444. This is a known set of bugs in Qt and from the tone of the discussion not likely to be fixed in KDE 4 any time soon. This blog posting is especially informative:

http://www.layt.net/john/blog/odysseus/the_good_the_bad_and_the_ugly

Revision history for this message
Sergio Callegari (callegar) wrote :

Apparently, some of the issues mentioned in this bug are slowly getting fixed.

At least it seems to be possible to control the duplexing (at least from okular), although it is awkward to do so.
The QT print dialogue has its own duplexing option which is controlled independently from the printer one and that seems to default to no-duplex. This should default to the printer config setting.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.