https://bugs.kde.org/show_bug.cgi?id=151614
Thomas Fischer fisc...@unix-ag.uni-kl.de changed:
What|Removed |Added
CC||fisc...@unix-ag.uni-kl.de
--- Comment #153 from Thomas Fischer fischer unix-ag uni-kl de 2011-05-06
10:56:20 ---
Hello,
Would it be too hard (or a viable partial solution) to use iText as a plugin
to
save/export the Okular annotations to a native PDF? And the same thing when
loading a PDF with annotations, informing the user that the PDF contains
attachments/annotations and if he wants to import the native/original
annotations to Okular's annotation format?
I came across with iText for Java very recently, and even though one have a
dependency here on Java to be able to use the library, could this be an option
to a user to have a choice to manipulate PDFs with iText on a plugin in
Okular?
Being iText open source and a great reference to manipulate PDF in the Java
world, I think it is pertinent to ask. Another solution would be to migrate
the
code/algorithm to Qt/C++ so it could be used here and in other OS projects, at
least while no one comes up with a better solution.
Porting a library from Java or C# to C++ can be quite an effort considering
that e.g. C++ has no garbage collection compared with Java and C#. Plus,
whenever there is a new version of iText, you have to port those
changes/bugfixes as well.
Keeping iText as it is and use it as an external plugin would be an option,
too, but adds external dependencies. If external dependencies would be no
problem, one could implement the generating/manipulating PDF part in pdfLaTeX
or other tools as well.
Using an external tool can only be a short-term solution until a real
solution matures (see below).
In the best case, Okular could use a shared library in C or C++ to do the PDF
manipulation. Some search revealed the following option (in no particular
order):
* The GNU PDF library which is still in its infancy but may be a future
alternative.
* Poppler seems to support some writing features, at least I found some mailing
list posting from 2008 on this. I don't know if it is supported by the Qt4
bindings yet.
* PDFedit is/was a Qt3 program to edit PDF files. I used it for some time, but
its inner design must have been horrible, as it got slower and slower the more
changes you made. Still, one could look at its implementation and learn how to
edit PDF files.
The most solid approach IMHO would be to look into Poppler's features and the
Qt4 bindings. If those bindings are not sufficient, make the necessary changes
for a clean, well-designed API. Once the API is mature, integrate it into the
PDF part (or inherit into a new KParts::ReadWritePart).
Let me see if I have some time during the weekend to dig through Poppler's
source code to give a more qualified comment here ...
(This is my personal oppinion, as I am not affiliated with the Okular
maintainers)
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Okular-devel mailing list
Okular-devel@kde.org
https://mail.kde.org/mailman/listinfo/okular-devel
