Bug 194586

http://www.qtsoftware.com/developer/task-tracker/index_html?id=207313&method=entry

I see... Should I keep this bug open?

I'm working on this one

*** Bug 208990 has been marked as a duplicate of this bug. ***

*** Bug 214306 has been marked as a duplicate of this bug. ***

*** Bug 219988 has been marked as a duplicate of this bug. ***

This feature has been merged into Qt for release 4.7.  Once that becomes available, each app will need to be updated to enable the option.  This will hopefully be possible for KDE 4.5.

I see, Qt is missing this feature as I understand it.

Could you possibly suggest a code snippet based on 
preprocessor settings that can already added now, 
so it would be enabled as soon as possible?

I mean something like

#ifdefined QT4.7
...
#endif

Regards
Ralf

Yep, sure can.

Just after you create the print dialog using KdePrint::createPrintDialog(), do something like:

#if QT_VERSION >= KDE_MAKE_VERSION(4,7,0)
    dialog->setOption(QAbstractPrintDialog::PrintCurrentPage);
#endif

Then once you are reading back the results from the print dialog you will be checking the QPrinter::printRange() setting to see whether to print QPrinter::AllPages or QPrinter::PageRange or QPrinter::Selection, you now need to check for QPrinter::CurrentPage as well, something like this:

#if QT_VERSION >= KDE_MAKE_VERSION(4,7,0)
    if (printer->printRange() == QPrinter::CurrentPage) {
        myPrintPageRoutine(m_myCurrentPageNumber);
    }
#endif

Hope that helps.  Once we have a firm release date for Qt 4.7 and know what the KDE 4.5 dependency policy is going to be, I'll look at whether to do this across all the major KDE apps.

Hey John,

thank you very much, I hope that developers C&P your snippet!
That would make their dialoges "KDE 4.7 ready" ;)

As the actual version number seems not to be fixed yet, it might be wiser to define a macro like #define __QT_READY_TO_PRINT_CURRENT_PAGE__ in a central place to be used globally. Then it is easier to change the condition in one central place the version needed changes to 4.6 or 4.8.

Apart from this, I can't imagine that a workaround would be that hard till then: PseudoCode:
If the "PrintCurrentPage" button is hit:
 -setPageRange(getCurrentpage(),getCurrentpage()) + Commit.

This is definitely in Qt 4.7, its now available in the official Gitorious 4.7 branch, so that's what we need to check for.  Don't be fooled by the "KDE_MAKE_VERSION(4,7,0)" macro name, that's just a KDE provided macro to create a version number, not the KDE version number itself.  It's the "QT_VERSION >=" part that holds the Qt version number that we need to compare.

Whichever version of KDE officially depends on Qt 4.7 will bea able to have the ifdef's removed.

*** Bug 240633 has been marked as a duplicate of this bug. ***

John? What about adding the needed code in kdeui, please?

Thanks for the reminder Pino.  

This cannot be globally enabled in kdeui as not all apps need it or can use it.  An app needs to:
* Have document pages
* Know what its current page is
* Know what to do when told to print the current page

So it can only be enabled at the app level.

The only SC app I can think of is Okular, and some apps in KOffice.  We can't do KHtmlPart or KatePart as they have no idea what page they are on until they have printed the document, their authors would need to make major changes to know page breaks in advance (and how would Konqi then know what the current page is?).  Any other suggestions?

I'll do Okular, and let the KOffice guys know they now have the option.

SVN commit 1134379 by jlayt:

Enable Current Page option in Okular print dialog if running Qt >= 4.7

Changed exported api so cc: to bindings.
CCMAIL: kde-bindings@kde.org

CCBUG: 194586



 M  +8 -2      core/fileprinter.cpp  
 M  +3 -2      core/fileprinter.h  
 M  +1 -0      generators/comicbook/generator_comicbook.cpp  
 M  +1 -0      generators/djvu/generator_djvu.cpp  
 M  +1 -0      generators/dvi/generator_dvi.cpp  
 M  +1 -0      generators/poppler/generator_pdf.cpp  
 M  +1 -0      generators/spectre/generator_ghostview.cpp  
 M  +1 -0      generators/tiff/generator_tiff.cpp  
 M  +1 -0      generators/xps/generator_xps.cpp  
 M  +8 -0      part.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1134379

SVN commit 1134631 by jlayt:

Whoops!  Didn't relise we had an API/BIC guarantee on Okular.  Restore previous
API and make it call the new API.

CCMAIL: kde-bindings@kde.org
CCMAIL: aacid@kde.org
CCBUG: 194586



 M  +5 -0      fileprinter.cpp  
 M  +10 -0     fileprinter.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1134631

(In reply to comment #14)
[...]
> The only SC app I can think of is Okular, and some apps in KOffice.  We can't
> do KHtmlPart or KatePart as they have no idea what page they are on until they
> have printed the document, their authors would need to make major changes to
> know page breaks in advance (and how would Konqi then know what the current
> page is?).  Any other suggestions?

The most important in unpaged documents (eg web pages) is for users to be able to restrict printing to the first page (eg airline confirmation, so that you don't need to bother printing the remaining 5-6 pages of dense legal blurb every time you fly :-)  Users may be able to select Page 1 in the regular page selector, but adding an obvious "Print current page only" button would be a major enhancement.

> I'll do Okular, and let the KOffice guys know they now have the option.

Excellent news, thanks very much. It is a critical function for anyone doing document development, typesetting, etc (which is why I'm still using kpdf and kdvi :-)

For unpaged docs defaulting Current Page to page 1 might be a bit misleading to users if it's a long document and they have scrolled to the middle or very end, they would expect what's currently displayed in the scroll view to be printed.  However since 4.4 you can choose the page range in web an text docuemnts if you are using CUPS for printing (i.e. 99% likely), and the dialog defaults the print range to pages 1 to 1, so it is just a single click like Current Page would be.  For any other page of the document it's a case of good guessing or using the print preview first.

Okular also needs additional functionality in the print page range as per acroread where you can print pages: 1,4,7,11-20,75 etc all in one go.  Since I had to got through the print dialogue 3 time to print page 74, 77 and 79 I can testify this is a feature sorely missed!

@david: this was also possible with kpdf under KDE 3.x

I am a teacher and used it a lot when I printed pages half size (2 on 1 page)
to save paper (ecology!). I just entered "1,1" as page range, and then enabled the option "2 pages on 1" for the printer.

Nowadays, it is a long and weary workflow, whenever I want to save paper:

I open PDF with open office draw, and then I copy the page, export to PDF (because Openoffice cannot use the "2 on 1" option), go back to okular then and print 2 on 1...

Acroread manages the "which page is it" problem by providing a small preview window in the print dialog which shows the current print page and the orientation etc.  This is a very nice feature that okular should aspire to.

As the original request is already provided in current kde relases, I'll close it