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