This way dvi and any other potential user gets it for free
The diff is huge, but the synctex files are just moves.
And the code in core/ is also mostly just a move from the generator_pdf.cpp code
Acked by Luigi
REVIEW: 120311
Diggory i think there was a misunderstanding in our discussion
The patch is unfinished (not goot to commit with a TODO)
and needs to be improved (need to find a way to not break ABI, QSize param should be const &) please
open a reviewrequest and we can discuss/finalize it there.
CCMAIL: diggory.hardy@unibas.ch
The text generator is the only one compiled now.
This version links for me but then doesn't find its KPart on startup.
TTS has been completely disabled as well as some other things like the
about dialog.
Includes some fixes from Albert:
* kscreen cmake fixes
Don't make libkscreen mandatory, give the proper version we need
* Fix the @since
* Kill Resolution and use a QSizeF
I first thought QSizeF didn't make sense, but well what's a dpi if not a number of pixels in width and some others in height?
* Remove unwanted const
* Remove unneeded utils.h includes
* Fix comments on realDPIXY()
* Make it compile in non X11
REVIEW: 111829
Unfortunately as we can't add new strings to stable versions it'd say "unwnown error" if that happens
Don't think it's too bad since this shouldn't be happening much
BUGS: 329562
Just use the pointer as id :-)
This is BIC and SIC, increase the soversion now to makes sure we don't forget in the future
Patch based in an earlier patch by Bogdan Cristea <cristeab@gmail.com>
REVIEW: 109115
The visible region was set in the PixmapRequest only a tiles manager was
available. Because of that the generator could check if it was supposed
to used tiles by simply checking if its normalized rect was null.
However is good to know the visible region even when a tiles manager is
not present. This way if the request is big enough to start a tiles
manager we already know the visible region and can change the
PixmapRequest accordingly.
and implement it in the pdf generator, others welcome to implement the function
for other generators
svn path=/trunk/KDE/kdegraphics/okular/; revision=1114944
for TextDocumentGenerator-based generators:
- EPub format
- Fictionbook format
- OOO.
This depends on Qt 4.5. Thanks to Qt Software (or wherever Thomas Z.
works) for QTextDocumentWriter!
It wouldn't be too hard to make this work for plucker (.pdb)
format, but that format doesn't work for me. It would be very
hard to make it work for other formats.
svn path=/trunk/KDE/kdegraphics/okular/; revision=855771
- 0..n-1 are the page indexes again
- -1 is for the fonts not reall belonging to a single page (or when no selective page extraction can be done)
svn path=/trunk/KDE/kdegraphics/okular/; revision=753866
This requires a generator to have a
MyGenerator(QObject *parent, const QVariantList &args)
constructor in order to be successfully loaded.
The OKULAR_EXPORT_PLUGIN macro was adapted, and the generators to provide it the about data; the protected Generator::setAboutData() is no more needed.
Remove the 'lib' prefix from plugins, unneeded now.
CCMAIL: okular-devel@kde.org
svn path=/trunk/KDE/kdegraphics/okular/; revision=744169
* 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
Added a non-virtual closeDocument() in the base Generator class: this way, particular closing routines can be implemented in the "low level" of a generator.
Apart the renaming, the logic of doCloseDocument() remains the same.
CCMAIL: okular-devel@kde.org
svn path=/trunk/KDE/kdegraphics/okular/; revision=723046
adapted the poppler and the chm generators to use that, instead of fiddling with the settings class
svn path=/trunk/KDE/kdegraphics/okular/; revision=712614
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
- renamed signalRequestDone to signalPixmapRequestDone to allow a future signalTextPageRequestDone
- added error/warning/notice signals to TextDocumentConverter and add meaningful error messages
to ooo and fictionbook generator
- code cleanup in chm generator
- print improvements and error notification in kimgio generator
svn path=/trunk/playground/graphics/okular/; revision=628124
$ command_that_produce_a_document | okular -
Expand a but the Generator API so a generator can directly read from the raw data read from stdin. Generators that can not read from raw data will open the temporary file with the saved data.
svn path=/trunk/playground/graphics/okular/; revision=622774
* add full API docs
* renamed getMetaData -> metaData
* removed supportsRotation in Document and Generator
* moved Permission and SearchDirection enums into separated header core/global.h
svn path=/trunk/playground/graphics/okular/; revision=619183
