and implement it in the pdf generator, others welcome to implement the function
for other generators
svn path=/trunk/KDE/kdegraphics/okular/; revision=1114944
Luigi's mail says
********
The attached patch changes a bit the handling of document informations
and the informations shown in the info page.
- document path is added to the information and a button allows you to
toggle between to file name (default) and the complete path;
- the number of the page is added to the information set by
documentInfo() and not by the properties dialog (so the latter will not
modify datas);
- the order of the information shown is the fixed now (see
orderedProperties).
*********
Then there are a few things of my own since some const here and there and adding three values to Key enum
Also it fixes wish 208999
BUGS: 208999
svn path=/trunk/KDE/kdegraphics/okular/; revision=1049872
This allows a resolution, if set, of that named destination when opening a document.
CCBUG: 192032
svn path=/trunk/KDE/kdegraphics/okular/; revision=967542
Few missing to be done in it:
- more checks when saving
- make it use a proper mimetype
CCBUG: 151614
svn path=/trunk/KDE/kdegraphics/okular/; revision=884597
Provide ways to register & unregister the view from a Document, and to get/set the view capabilities.
svn path=/trunk/KDE/kdegraphics/okular/; revision=801657
On the Document/Generator side, introduce a proper interface for the purpouse.
On the GUI side, add a new "Save As" function that save the changed document to a location.
The action is enabled only if the current backend can provide the functionality.
svn path=/trunk/KDE/kdegraphics/okular/; revision=784661
This way we can tell to "merge" in a smart way the new pixmap request with the enqueued ones of the same ID.
Add a (private) slot to refresh all the pixmaps of a page.
svn path=/trunk/KDE/kdegraphics/okular/; revision=783259
This way, standard info keys can be used without adding manually the key id and the translated label.
svn path=/trunk/KDE/kdegraphics/okular/; revision=772350
* Add FilePrinter class to enable printing via postscript files
* DJVU, PDF, and PS backends print FilePrinter
* All backends enable printing of bookmarked pages
* Print and Print Preview actions enabled/disabled depending on backends
printing ability
Note that FilePrinter only works on *NIX platforms with Cups, lpr, or lp.
svn path=/trunk/KDE/kdegraphics/okular/; revision=741990
*** Note this is not a complete port, most of the generators use the
printFiles method which Qt 4.3 does not support, these have simply
been commented out until we find a solution. At least it removes
the dependency so we can remove from kdelibs.
svn path=/trunk/KDE/kdegraphics/okular/; revision=725660
- make the Generator internally keep an pointer to the private class Document, so we can access easily to the Document' stuff
svn path=/trunk/KDE/kdegraphics/okular/; revision=712498
Instead of manually requestion actions and other stuff, we just make the interface as gui client, requesting and integrating it in the part gui.
Also, rename the Generator's componentData() to ownComponentData() to avoid clashing with KXMLGUIClient.
svn path=/trunk/KDE/kdegraphics/okular/; revision=705933
* Update some copyright years and mail addresses
* Search does not block the GUI anymore YUHUUUUU
Well, it it does but it's almost unperceptible, that means the searching methods of Document no longer return a bool but a void and the Document::searchFinished signal is used to know if something was found, nothing was found or the user pressed the cancel button !YES! one can cancel search now :-)
* TextPage no longer holds the area and the current transformed area, it took TOO MUCH memory, now we transform the area each time, it's much more CPU intensive but i could not measure a time loss while searching big documents and i could measure HUNDREDS of MB of usage less.
* MICRO optimization: Change some code to not detach some containers
* I still don't have ADSL so this is something like a "blind" commit, Pino will check it compiles against current KDE, not against what's on my computers
svn path=/trunk/KDE/kdegraphics/okular/; revision=699701
Instead of having a synchronous function that extracts all the information at once, use a function to read the fonts of a single page.
This way, we can get all the result step by step (aka page by page), and possibly in an asynchronous way.
The resuls of the font "scanning" are sent via signals, as well the end of the work.
So, instead of block waiting for the results of all the document at once, the Fonts tab in the properties dialog can have a progress bar with the progress, and the results (the fonts) that are added incrementally to the list.
Only two minor things are left:
- the process is always asynchronous at the moment, as the only generator that can provide this kind of information is the Poppler one (safe)
- there is no check for duplicate fonts
But they should be easy to solve.
svn path=/trunk/KDE/kdegraphics/okular/; revision=685002
Michel Ludwig
Albert Astals Cid
Kevin Kofler
Pino Toscano
Armin Berres
John Layt
Tobias Koenig