Version: (using KDE 4.2.3) OS: Linux Installed from: Unspecified Linux When printing from Okular (but it is certainly not specific to Okular) with the pdf printer ("print to file (PDF)"), the multipage option is ineffective. The resulting pdf (think to change the output file which by default is the open file...) is the same than the original. Note that this option works with real printers. Only the pdf printer (and maybe the PS printer, I didn't try) has this problem.
*** This bug has been marked as a duplicate of bug 155695 ***
That's not the same bug. bug 155695 is about printing several times the same document. Here it is to have a new pdf with, for each sheet, several pages of the original document. For example 2 pages per sheet -> the original A4 pages will be transformed to A5 and print 2 by 2 on A4 sheets.
I confirm this bug. This option doesn't do anything when printing to pdf file and output is exactly the same as input file.
I also confirm this bug.
*** Bug 195684 has been marked as a duplicate of this bug. ***
This is a bug in Qt, need to send upstream.
Just to clarify, this is a different bug to the "Okular only prints a once" bug caused by Qt always returning 1 for number or copies when using CUPS. When printing to a PDF Qt still only returns 1 when it should be telling the app the correct number of copies to render.
Hello, the only relevant upstream bug seems to be this one: http://bugreports.qt.nokia.com/browse/QTBUG-1314 and it's not even a bug but a discarded feature request. It would be nice if some KDE people who know the internals better could clarify the issue for the QT guys.
Previous comments have only mentioned the very specific case of printing into a PDF in Okular. I confirm this for Postscript output as well as for printing from other applications, e.g. an HTML page in Konqueror. As it seems to work for real printers (I haven't tried myself), I think it can't be related to the rejected Qt feature request mentioned by Daniel, but must be implemented differently in KDE (probably by calling psnup). Also this shouldn't be treated as a feature request, but a bug. Multiple pages per sheet used to work in KDE 3, so it's a regression.
To clarify further. The n-up feature is implemented by KDE as an add-on to the Qt print dialog, basically we cheat by intercepting the print job after it has been rendered by Qt and add on the CUPS n-up parameter. As such it only works with CUPS printers, not the print to file options or any other platforms. The short term fix is for Qt to add a signal to QPrintDialog so we know when "Print to File" has been selected and so we can disable our n-up option. The long-term fix is for Qt to implement n-up support internally in QPainter so it works with all printers on all platforms, including print to file.
*** Bug 241123 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > To clarify further. The n-up feature is implemented by KDE as an add-on to the > Qt print dialog, basically we cheat by intercepting the print job after it has > been rendered by Qt and add on the CUPS n-up parameter. As such it only works > with CUPS printers, not the print to file options or any other platforms. So how did it work on KDE 3, and why isn't it possible to implement it in the same way in KDE 4? I suppose that the old Qt didn't have n-up support either. Disabling the option is not really a solution. It still means that I need to use a different, working application like Gnome's evince to do the job.
> Disabling the option is not really a solution. It still means that I need to > use a different, working application like Gnome's evince to do the job. you can install the package "pdfjam" and use, for example, the command "pdfnup file.pdf --nup 2x2" to get the same result without having to install gnomic stuff.
In KDE3 we had our own printing architecture which worked directly with ps files. The apps rendered the document and KDE3 converted that to a ps which we could then manipulate using command line tools to achieve n-up before either saving as a PDF or sending to CUPS to print. However the code went unmaintained and was not cross-platform so had to be reluctantly discarded for KDE4. We now use the Qt printing architecture which is maintained and cross-platform, but the drawback is once the app renders the document we no longer have access to the print/save file to do anything to it, we have to ask CUPS to do the n-up printing instead, or wait for Qt to support it. I suppose we could come up with some hack where we wait for Qt to save the PDF file and then call pdfjam or similar in the background to convert the file. Solving this is fairly low on my list of priorities, there are more important missing options to fix first. Besides I'm struggling to understand the use case for this, why would you need to n-up a digital document?
>why would you need to n-up a digital document? in my case, I use this option to print out the slides of the lectures I'm attending to. To save paper and ink, I print 4 pages per sheet, duplex (my printer is not duplex-capable, so I print odd pages first, put the paper back in and then print the even pages). This is almost all the printing I do. Since switching to KDE4 I've never been able to print in this way, so I need to try tricks, like printing first 4 pages per sheet to a new PDF file, and then print only its odd/even pages to the printer, etc.
(In reply to comment #15) > Besides I'm struggling to understand the use > case for this, why would you need to n-up a digital document? It's very useful for a) proofreading the nup-configuration: Is the layout (columns first vs. rows first, landscape vs. portrait) correct? For double pages, are the front and back sides still ordered correctly? b) preparing pdf documents for later printing on a machine where psnup/pdfnup are not available. This may be a print shop, a windows printer or just technically less apt friend.
Confirming bug still exists in KDE 4.5.3.
I am just another user who would like to have this feature in okular. Being every printing system over the Earth dumb as a cow when it comes to counting pages, I need to print to an intermediate pdf file first if I want multipage-double-sided stuff. Let's call it ecology, let's call it economy, let's just call it that I don't like having 200 pages around when I can just have 50. I can confirm that evince can do this, for those that eventually stump in this bug like I did and have no idea how to achieve this in Linux.
Still happening in Okular 0.14.3 and KDE 4.8.4. I set to print 2 pages on 1 but without effect. All I get is the same PDF. Please solve this issue, it's really annoying - this basic feature does not work. By the way I found a little workaround. Install cups-pdf, then you will have another virtual printer (CUPS). With cups printer multiple pages on 1 page option works as expected. The only drawback is that CUPS generates files to ~/PDF folder. You can't change that directory nor the output filename. So after printing with CUPS, you have to find and copy resulting file from ~/PDF to your destination.
(In reply to comment #15) > I'm struggling to > understand the use case for this, why would you need to n-up a digital > document? I generate a pdf from a spreadsheet for a financial report at the AGM of a professional association. In this context you don't want too much distracting information cluttering the screen and the people at the back have to be able to read it. The members get a pdf copy of the report after the meeting. They don't want to have to keep clicking through a mass of pages and are close enough to read smaller type. So I put more than one slide on each page.
I can confirm this bug on KDE 4.14.10 using Okular 4.14.3 (Gentoo). This bug seems to be related to Bug 342158.
I also confirm this bug. KDE 5.7.2 using Okular
*** Bug 342158 has been marked as a duplicate of this bug. ***
This bug is still present in Okular 1.3.3. KDE Plasma: 5.12.6 KDE Framework: 5.45.0 Qt: 5.9.4
(In reply to Marcos Paulo de Souza from comment #25) > This bug is still present in Okular 1.3.3. > > KDE Plasma: 5.12.6 > KDE Framework: 5.45.0 > Qt: 5.9.4 How is this possible? I thought n-up printing had long ago been removed from the Qt print dialog. See Bug 196303. I can confirm that in my setup (Plasma 5.14.2, Framework 5.51.0, Qt 5.11.2), there is no option for n-up printing in the print dialog (either to the PDF "printer" or to any physical printer) for any KDE application, including Okular 1.5.2. If I need n-up printing I need to do this from the command line or from a GTK+ application.
(In reply to Tristan Miller from comment #26) > How is this possible? I thought n-up printing had long ago been removed > from the Qt print dialog. See Bug 196303. > For Qt 5, this option has been moved to the "Properties" -> "Page" tab. There's an option "Pages per sheet", so it's still there; it has just been moved to another place in the print dialog.
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have resolved this bug. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann