Do not assume that there can be only one objectrect in a given point, remove const ObjectRect * KPDFPage::getObjectRect( double x, double y ) const and add const ObjectRect * KPDFPage::hasObject( ObjectRect::ObjectType type, double x, double y ) const instead
BUGS:101648
svn path=/trunk/kdegraphics/kpdf/; revision=398214
Enrico, maybe you don't like the way of filling the KListView, the properties dialog asks the document if it has fonts (in the future maybe we support formats that don't have fonts), then create the KListView and pass it to the document that passes it to the generator that fills it, the "problem" is that now the generators are GUI aware.
svn path=/trunk/kdegraphics/kpdf/; revision=398206
A good document to test is cups/idd.pdf that has links 1, 1.1, 1.2 and 1.3 all to the same page but with different viewports
Seems to work but a review of the code is always good :-D
svn path=/trunk/kdegraphics/kpdf/; revision=396528
--enable-force-kpdf-drm is a configure option, it defaults to NO, if YES DRM is ALLWAYS obeyed
skip_drm is a kiosk option, it defaults to YES, if NO, means the user is not authorized to skip DRM and DRM is ALLWAYS obeyed
if previous options are no and yes, the user sees a GUI option called Obey DRM limitations that defaults to YES but the user can set to NO from the GUI
svn path=/trunk/kdegraphics/kpdf/; revision=394412
How it is going to end:
- Exists a configure option called --enable-kpdf-drm that is DISABLE by default and you can use to FORCE kpdf obeying DRM
- Exists a kiosk option called skip_drm that is true by default and the admin can set to TRUE to FORCE kdpf obeying DRM
- Exists a GUI option called Obey pdf limitations that is shown if skip_drm is true, that option is ON by default, that means DRM is obeyed but the user can disable it from the GUI
Hope that will please everyone
Please can somebody with better english than me check that the wording i used is actually correct english? Thanks
svn path=/trunk/kdegraphics/kpdf/; revision=394212
Olaf can you check that fixes your wrong paper format complaining printer too?
CCMAIL: 98837@bugs.kde.org
BUGS: 100003
svn path=/trunk/kdegraphics/kpdf/; revision=393859
IMHO this is not a feaute but a bug-fix as if this is not implemented we let the user copy text and print from PDF that are protected against and wether we may like it or not is what the spec says and we could get in problems if someone copies text from a protected PDF using our tool.
svn path=/trunk/kdegraphics/kpdf/; revision=390866
User Interface: added a toolbox for selecting an annotation tool without
polluting the toolbar (pageviewtoolbox animated widget). Icons of that
toolbar are gimped version of ones in nuvola icontheme.
Core: added annotation class. this will support all features (except for
silly ones (really there are some!)) from pdf 1.6 specs but abstracted
in the kdpf way. (api changes in progress...)
About annotations: only some incomplete interfaces are in plasefor now.
Every type of pdf annotations has tens of parameters. I think we'll render
correctly everything but provide only simple and useful tools for making
annotations over the pages, otherwise a 'Qt designer like' property view
will be required to do fine adjustment over the crappy thousands of
settings. (and we're aiming at a quick and simple viewer with lots of
coolness, not chaos).
Have fun!
svn path=/trunk/kdegraphics/kpdf/; revision=388699
- Keep the original url on the document so we can open relative file names
- Add Enrico and my copyright
svn path=/trunk/kdegraphics/kpdf/; revision=386244
Removed old code, reworked bad code.
I have no more reported crashes now.
No plans for additions or code changes till 3.4 release.
Thank you all kpdf users, Have Fun!
svn path=/trunk/kdegraphics/kpdf/; revision=385897
Albert Astals Cid
Enrico Ros
Dirk Mueller
İsmail Dönmez
Jakub Stachowski