Version: (using KDE KDE 3.94.0) Installed from: SuSE RPMs OS: Linux All annotations are stored in the .kde4/share/apps/okular/.../... folder. If the annotations are only used on the local computer this is pretty fine. But if for instance I want to send somebody the document with my annotations (e.g. proofreading) I have to add the xml file separately to the email. The receiver has to store the files at the correct locations because of the absolute path name in the xml file or edit it and correct this. That's not very practicable. Another aspect is file renaming. I added some annotations to a pdf file and renamed it. After I reopened the file all annotations were gone. As far as I can see the problem is that the xml file is not updated. The main question is if it is realy sensible to store the data separate from the document. In my opinion it would be much easier for the user to have the documents somehow combined. Here are some suggestions: * in the same folder + same name as document + different extension (+ compressed ?!) * in the same file - store directly into the file as done by many annotation tools * create a new ''file format'' so that the document with all annotations is stored with all annotations in one file (e.g. compressed file similar to odf) These are only some suggestion. So maybe there is even a better way to deal with this problem. Best Regards, Joachim
> Another aspect is file renaming. I added some annotations to a pdf file and > renamed it. After I reopened the file all annotations were gone. As far as I > can see the problem is that the xml file is not updated. I doubt this is solvable. Let's say you have a.pdf and okular has the (internal) .xml for it. Then, you rename it to b.pdf, and you open it in okular. How can okular know that b.pdf was renamed from a.pdf? > * in the same folder + same name as document + different extension (+ compressed ?!) While it can look a better solution (you have the metadata .xml aside the document), this can both pollute the places where your documents are (ok, we pollute the ~/.kde/share/apps/okular/docdata as well, but at least they are together there) and not always be doable (think about documents in read-only places). > * in the same file - store directly into the file as done by many annotation tools Yeah, this is the top preferred solution, who wouldn't it? ;) The problem is that we have no way to change something in the documents we open. Furthermore, it would not be feasible if the document type does not support annotations (eg PS, DVI, etc), so in case a "fallback" solution for those is needed indeed. > * create a new ''file format'' so that the document with all annotations is stored with all annotations in one file (e.g. compressed file similar to odf) That was actually the idea we had so far: have a sort of mini-wizard (or a simple menu action) to create an archive containing document + metadata. Of course, the fact that "we had the idea about..." does not imply anything, we're always open for discussion!
Moreover, if you have two files with the same name, them share notes.
Can you explain "we have no way to change something in the documents we open"? I'm not sure I understand what you mean by that. For PDFs, it would be great to annotate the way Adobe's tools do -- the results work for every PDF reader. Alternatively, Okular could store annotations in PDFs using XMP; there's at least one free implementation already: JempBox (BSD, Java).
> Can you explain "we have no way to change something in the documents we open"? I'm not sure I understand what you mean by that. > Okular could store annotations in PDFs using XMP Okular can NOT change in any way the document it opens. This is not really an okular limitations because of itself, but - pseaking about PDFs - the PDF library we use do NOT support changing (either adding/modifying/removing) something in the document.
Hi, I just try okular and it's a very software but like some other people I'm a little bit disapointed by the annotations tools. I understand that the library actually used cannot add any informations to the pdf but for most people the annotations tools is expecting to work like the one from adobe and so add the information to the file. I'm a little bit afraid that this function will disapoint so many peolple that it will give a very bad image of okular. It's not clear at all that the annotations are not stored in the file. Perhaps the xml file can be use but not hidden in a strange place (for most people) and perhaps you can assure that the xml file is corresponding to the file if it use a md5 (just a suggestions I don't know if that can work). In this case the xml file could be associate to the file without a link to the name and/place where it is stored. In addition an option to save the xml file in the another directory than .kde/... file can be useful and add the possibility to open this file from okular (something like open annotations) the md5 if stored inside the xml file can provide the information if the xml file correspond to the pdf file or not. Just some suggestions. Anyway great work :)
How about saving the .xml as an attachment in the PDF itself? I understand this doesn't work for PS and DVI (and only in okular, but at least it would survive moving, renaming and sending around) but I'm willing to guess most people would want to use it with PDF and still needs to change the PDF, but it should be vastly easier than adding another layer?
> How about saving the .xml as an attachment in the PDF itself? Sigh, it seems I have to quote myself... > Okular can NOT change in any way the document it opens. So, for now, please *forget* anything that manipulates the document. If that would be possible, okular would *already* do that!
Just found this report. When I first used okular some weeks ago I had a really hard time finding the annotations. Sad that poppler does not support adding a file to a pdf.
I'd like to express my support for the proposal described in comment #5. I'm a PhD student who has a ton of pdf files. I've been looking for a pdf reader that can annotate pdfs. Since I store the pdfs on a server and use Tellico to index them, when i view a pdf, I typically do it via fish (i.e., over ssh). Tellico copies the pdf to /tmp and prepends some garbage (pid, I think) to the filename. When I annotate a pdf, the XML file's documentInfo url tag points to /tmp and to a filename that will never exist again. It'd be great if rather than associating the annotations to filenames, okular could install associate XML files with PDFs based on hashes (e.g., sha-1, md5, etc.) of the PDF. This would allow me to view my annotations regardless of the particular (temporary) filename associated with a PDF. Thanks, Micah
I support a quick solution for this problem. Like it is now, it is unfortunately not usable and can indeed be very disappointing for people. And that is a shame, because Okular is a very very great application.
On Wednesday 16 January 2008 12:47:54 am jsvrp.gw@gmail.com wrote: [bugs.kde.org quoted mail] I support it too. Do you have a patch for this "quick solution"? Or even a suggestion for how to make it work, given the previous discussion? [I have a possible long term strategy, but that won't be "quick", and it may not even be practical] Brad
I guess the "okular file format" is THE way "* create a new ''file format'' so that the document with all annotations is stored with all annotations in one file (e.g. compressed file similar to odf)" BTW I want to add that also in my mind this feature is the very key for okular being successful and match with users needs. To understand this it should be enough to look to the may programs that attempt to add and save annotations in pdf. There is a bulk of these program, each with his own limitations, both on linux and on windows. It is time for linux to have THE tool. Don't you think?
Nothing else will be able to read it. Okular doesn't have that much popularity...
I think the developer are smart-enough to make it comaptible, in the sense that you can *always get the original PDF out of the .okular*, which will probably be a smart way to make the PDF and the XML for the annotations travel together. Until poppler cannot edit a PDF or a new library for PDF-editing is published I don't think we can do much better than this. Indeed pdf-edit development doesn't run fast at all ... On the other hand this "okular archive" will be a "portable annotated document", which works on every machine running okular (i.e your laptop and your desktop(s)) irrespectively of the fact you moved or renamed the file. There is also some chance for this approach to provide annotated DjVu, Tiff and PS as well and this is not irrelevant too. Finally, when it will be impletented, you can always come down to a PDF just printing the file to a PDF. This would allow (Acrobat) user to read the PDF as you edited and seems to me a great step ahead in features as well as a quick workaround for a basic functionality till basic facts about Poppler don't change. Say it is a very good looking patch. At least IMHO ... 15 Jan 2008 20:25:39 -0000, Brad Hards <bradh@frogmouth.net>: [bugs.kde.org quoted mail] I think the developer are smart-enough to make it comaptible, in the sense that you can *always get the original PDF out of the .okular*, which will probably be a smart way to make the PDF and the XML for the annotations travel together. <br><br>Until poppler cannot edit a PDF or a new library for PDF-editing is published I don't think we can do much better than this. Indeed pdf-edit development doesn't run fast at all ... <br><br>On the other hand this "okular archive" will be a "portable annotated document", which works on every machine running okular ( i.e your laptop and your desktop(s)) irrespectively of the fact you moved or renamed the file. There is also some chance for this approach to provide annotated DjVu, Tiff and PS as well and this is not irrelevant too.<br> <br>Finally, when it will be impletented, you can always come down to a PDF just printing the file to a PDF. This would allow (Acrobat) user to read the PDF as you edited and seems to me a great step ahead in features as well as a quick workaround for a basic functionality till basic facts about Poppler don't change. <br><br>Say it is a very good looking patch. At least IMHO ...<br><br><div><span class="gmail_quote">15 Jan 2008 20:25:39 -0000, Brad Hards <<a href="mailto:bradh@frogmouth.net">bradh@frogmouth.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ------- You are receiving this mail because: -------<br>You are the assignee for the bug, or are watching the assignee.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=151614">http://bugs.kde.org/show_bug.cgi?id=151614 </a><br><br><br><br><br>------- Additional Comments From bradh frogmouth net 2008-01-15 21:25 -------<br>Nothing else will be able to read it. Okular doesn't have that much popularity...<br>_______________________________________________ <br>Okular-devel mailing list<br><a href="mailto:Okular-devel@kde.org">Okular-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/okular-devel">https://mail.kde.org/mailman/listinfo/okular-devel</a><br></blockquote> </div><br>
I'm still very dubious about the concept. However I am willing to give this a try. Conceptually, the idea will be that we can "export as" a .okular (which will likely really be a zip file, implemented using KIO::KArchive). That should be able to be done with just a poppler generator change. Then I'll add a new generator that can open .okular format files, and "export as" PDF. Issues: * I'm not sure whether one generator can really call another, so that might be a big problem. * It might get very confusing if you sometimes edit the PDF and sometimes the .okular. * It might require substantial changes in the okular core, because this will be the only place where we don't store the docdata in .kde/share/apps/okular. * It won't be necessary for PDF files if poppler gets useable storage capability, and will probably then bitrot.
On Wed, Jan 16, 2008 at 09:31:25AM -0000, Brad Hards wrote: Hej, > However I am willing to give this a try. Instead of fixing the symptoms we should start providing a working implementation for modifying PDF directly. There is no need to make it part of poppler, as poppler is aimed to be a PDF viewer, so the whole internal design is about reading PDFs, not writing. However we could for example borrow some code from pdfedit (a Qt based application which borrows code from kpdf ;)) which can modify PDF documents and append objects. So the poppler_generator could use poppler for reading the PDFs and a pdfedit-derived library to add/edit annotations in the document. Ciao, Tobias
As far as I know PDFedit is aiming to the definitive solution to the problem of this thread. Development is quite hard though. I just updated to 0.3.2 to check the progress and I find a situation not so much improved. For instance PDFedit get slower and slower as you add more and more annotations (three or four are enought to make it apparent). I was told it to be linked to QSA library and Qt3. They plan to move to qt4 and fix the QSA thing, but in the several months elapsed since I asked, nothing changed. This look to be a quite involved thing. Given PDFedit is the best choice for a robust edit feature in okular, I think it will be reliable and full featured only in the mid long term. Therefore I think okular should find a solution for its first stages (one year or so, maybe more). Cross-finger for PDFedit coming soon and finding a good workaround in the meanwhile is maybe the solution. 16 Jan 2008 12:32:58 -0000, Tobias K
Waiting for more elegant solutions, okular might store annotations inside documents using something like: "pdftk doc.pdf attach_files annotations.xml output doc.pdf" for pdf "djvused doc.djvu -e 'set-ant annotations.xml'" for djvu "wrjpeg -cfile annotation.xml doc.jpg > doc.jpg"" for jpeg and so on... Where this is not doable okular might fallback to the present solution.
poppler has an almost working solution for data back to pdf, of course work needs to be done on the annotation side and even this would work this solves only the problem for PDF format which shall i remember you it is not the only format we support.
On Wed, Jan 16, 2008 at 07:53:16PM -0000, Albert Astals Cid wrote: Hej Albert, > poppler has an almost working solution for data back to pdf, > of course work needs to be done on the annotation side Ohh really? I wasn't aware of that. Where is the code which does that? > and even this would work this solves only the problem for PDF format > which shall i remember you it is not the only format we support. Right, but the most important document-wise. For the other formats we can stay stucked with the current solution or try to add annotations there to the original document as well. Ciao, Tobias
http://lists.freedesktop.org/archives/poppler/2007-December/003276.html I will be merging that on poppler head/trunk/master soon(tm)
libdjvulibre, the library okular use to render djvu documents, holds the capability to insert arbitrary metadata in a djvu paper. Why are there no plans to exploit that capability to store annotations?
Who said there are no plans? :) Anyway, this problem is still valid, no matter what is the document type. Why? You cannot rely on the backend to save the annotations back to the document it supports, especially that the format could not even support annotations. So, a common solution *must* always be found.
On Thu, Jan 17, 2008 at 08:43:19PM -0000, Pino Toscano wrote: Hej Pino, > Who said there are no plans? :) > > Anyway, this problem is still valid, no matter what is the document type. > Why? You cannot rely on the backend to save the annotations back to the document > it supports, especially that the format could not even support annotations. > So, a common solution *must* always be found. We could show a dialog to inform the user that the loaded document doesn't support storing annotations inside the document but that it will stored in a separated file. Ciao, Tobias
*** This bug has been confirmed by popular vote. ***
Perhaps pdftk can be of help. It allows adding watermark etc.
I have started to work on a quick and dirty program which reads the okular xml file containing annotations for a specific pdf file and uses podofo to add these annotations as (real) pdf annotations to the file. Right now it only handles text annotations (i.e. okular type 1) and even that not perfectly (i.e. it doesn't preserve creation time, author etc). If you think this is not a complete waste of time, I can improve it and put it up somewhere for download.
@Jonathan: Please upload somewhere, I think it is desperately needed. Annotations that can't be send to anybody and that are not placed nearby the annotated file itself are nearly useless (can't be used for desktop search and can't be used to send to somebody).
O.K. So I've prepared some packages which can be downloaded from http://jonathan.verner.matfyz.cz/index.php?action=static&spec=download be warned that the program is very crude and hackish at the moment. It doesn't yet cope well with non ascii characters in annotations, only works for text annotations and a major shortoming is that once the annotations are merged, they cannot be edited with Okular. If I have understood it correctly, Okular will gain the ability to save the annotations back to the pdf, so this program should not be needed and I am hesitating whether I should devote more time to it.
How about just adding print support for annotations? Many modern distros, including kubuntu, automatically install a cups-pdf driver. Thus, if okular would just *print* the annotations, there would be an immediate workaround for many users: just print to the built-in cups pdf "printer" and bam, a new PDF, annotations and all. I'm sure it's not a perfect solution, but it would be a useful bandaid.
@comment #30: you cannot do that. Poppler (the PDF library currently used) can only generate PostScript as print, and PostScript has no such idea of "annotations". On the other side, Poppler can actually save the changes to the document, but cannot yet edit the annotations. Something that is missing is the idea that this system must be available for all the kind of documents Okular can read and will do some day.
I'm wondering if there has been any activity on solving this bug in the past few months, or are things at a standstill regarding the annotations feature? As a PhD student this bug is the most anticipated feature in all of KDE4 for me, and has been ever since I heard the first early reports on Okular's development. Two main suggestions have been provided so far: 1. Recent LibPoppler patches allow saving back to PDF files. Okular would have to update its framework to allow saving to files in general, and saving annotations to PDF files in particular. 2. Bundle the annotations XML with the document into a new bundle format (.okular), which would work with any document type but would be a solution specific to Okular and other programs that add specific compatibility for this format. I have a couple more suggestions: 3. Rather than save the annotations XML into an internal directory, attempt to save it in the same directory as the opened document matching the filename (ex. for document.pdf create a file document.pdf.okular in the same directory). This will make the annotation file more accessible to the end user and would simply solve many of the usability issues with the current system. 4. Okular needs to add the ability to extract annotations that are 'baked-in' to the PDF file into its own XML format, so that the user isn't left with the situation where half of his annotations are in one place/format and half are somewhere else for the same document. 5. If no other work is being done on an annotations solution, I would love to see Jonathan's packages added into the main distribution. Even if it is an incomplete, hackish, temporary PDF-only solution, it is MUCH better than not having anything until a fully robust, document-universal solution is finally ready many more months/years down the line.
I've often seen the question "Ok, you talk about PDF but what about the other formats?". For me this question is pretty simple. For file formats that can't store any kind of annotations (I read in this thread that dejavu is also capable of annotations) we can still use the present solution or go with this ".okular" format thing. Even though I think this is a waste of time since ".okular" will never be supported by anything else (most likely). I actually liked the idea of Tobias who said that if you put annotations in a file without annotation storage capabilities okular can warn you that these annotations will be stored in an external file. To get a hold of these information there could be a button for these formats like "export annotations" or something like that. BTW did something happen with "poppler can edit pdfs" or is there a plan to implement pdfedit into okular?
I think annotaions are useless if you cannot exchange them with a adobe-reader-user. Isn't pdf a format with an open specification? Also, I (and I think most other users, who don't read the manual or something else where this is documented) expect annotatations to be embedded in the pdf. This was a really bad surprise..
@Will Jordan (comment #30): > 1. Recent LibPoppler patches allow saving back to PDF files. ... but just for editing values of form fields, nothing more. (And Okular already makes use of that.) > 2. Bundle the annotations XML with the document into a new bundle format > (.okular), which would work with any document type but would be a solution > specific to Okular and other programs that add specific compatibility for > this format. Like said in the original bug report and in comment #1? > 3. Rather than save the annotations XML into an internal directory, attempt > to save it in the same directory as the opened document [...] What is not that clear so far, it seems, is that the internal XML does not contain only annotations, but also various data (even "confidentail"), like values of form fields, the URL of the document, the last 10 steps in the vieweing history, etc. And tracking two different internal files is not something that makes things easier. @Volker (comment #34): > Isn't pdf a format with an open specification? Do I have to comment, or you can understand yourself that PDF readers and writers do not grow on the trees overnight? > Also, I ([...]) expect annotatations to be embedded in the pdf. And I would expect (not completely, but still a bit) people to *read* the previous 30+ comments in this bug report, before commenting. Oh, and I would also expect a bit more of patience, given that all the pieces in the chain have no infinite time.
Hi Pino, > ... but just for editing values of form fields, nothing more. (And Okular already makes use of that.) Is this library something that could be expanded to support annotations, and would Okular be able to make use of this if it was? Is this something that is planned or being worked on? > Like said in the original bug report and in comment #1? As I said, was providing a recap. Is this .okular file format something that is planned or being worked on? I am still interested in hearing (without demanding that PDF reader/writers grow on trees overnight!) if there was ever a decision made as to what the best (current/temporary) solution to this bug will be, how far along the implementation of this solution is currently, what (if anything) we're waiting for development from other packages/libraries, and if you could use any additional help with any aspect. Some of us (myself included) are willing to contribute to the project if any help is needed. However, until we are brought in the loop, continuing to ask about this bug and a solution is really all we're capable of contributing, which is a shame.
Several things to say. First of all, IMHO, PDF/PS/DVI and some others are not supposed to be edited in any way (yep, I know about PDF interactive features and that's not sane, IMO). They're final, finishing formats, so to say. Changing such files is not a good idea. At least I'm not expecting _viewer_ to _change_ my files (yep, Adobe seems to be doing that and that's not a good reason to follow, IMO). Then, there's privacy issue. What if I want to annotate some document, but don't want to share annotations? To summarize I expect document data to be verbatim, not changed by viewing and I don't want to mess _my_ data (annotations) with the document data. Then, as Okular user with ability to annotate any document (not only PDF), I'd expect that it will also give ability to share this annotations for any document format. So, IMO, separated annotations as it is now is absolutely fine and sane way of things. Of course, if anyone implements _option_ to save annotations in the PDF, I have nothing against that, but as long as it is _option_ and not default one. We just have a problem of transmitting metadata (annotations) along with the document. I don't think .okular format is good way to handle it (yet another file format (even if it's something like tarball in reality), doh!), it's better just to have two "Export Okular metadata" (or "Export annotations") and "Import Okular metadata" buttons that will just copy xml from dark internals of ~/.kde4 to user-specified place and that's it. BTW, saving xml in the same dir by default is not a good idea, IMO, don't litter user directories with strange files! Just give ability to export/import. Now, one another thing to handle is document renaming, but as pointed above several times, that is easily done by hashing (MD5/SHA1, pick any, there is no need for strong cryptographic function) and checking hashes when detection by url gives nothing. Well, that's my IMHO on this popular issue, if anyone cares.
"First of all, IMHO, PDF/PS/DVI and some others are not supposed to be edited in any way (yep, I know about PDF interactive features and that's not sane, IMO). They're final, finishing formats, so to say. Changing such files is not a good idea. At least I'm not expecting _viewer_ to _change_ my files (yep, Adobe seems to be doing that and that's not a good reason to follow, IMO)." A PDF file is basically noting else as a digitalized book. I'm reading a book currently, in which I make comments. Yes, sure a book is also a finished format - but who's making the annotation of interesting parts on an extra sheet of paper? Do you noticed that all people are talking about annotations within the document and not changing the content of the file? "Then, there's privacy issue. What if I want to annotate some document, but don't want to share annotations?" If you want to do that, hold two different files - the original and the annotated - you will have the freedom. Currently you don't have the freedom to share the annotations with other or the freedom to share it with your second computer which use another pdf reader. "Then, as Okular user with ability to annotate any document (not only PDF), I'd expect that it will also give ability to share this annotations for any document format." I really like this kind of fundamentalism. Everybody knows the exact date when all possible formats will have the same ability to store the same amount of data (like annotations): NEVER There is only a virtual reason to demand this - no real reason. Everybody should respect everyone's opinion and the strength of the OpenSource world is that minorities could configure the system which is appropriate for them - but ignoring the wishes of the vast majority is for sure no good idea. I can clearly understand Pino's arguments that creating good tools in the pdf area are a lot of work - but the goal have to be a viewer which has the ability to store annotations within the pdf file. For everybody who needs that feature right now - have a look at the direct opponent of okular on Mac OS X - it's only called "Viewer" - with these annotation feature.
> Do you noticed that all people are talking about > annotations within the document and not changing > the content of the file? Yep. And you effectively _change_ the file when you store annontations inside it. And that's what I don't want to have, at least by default. Hence writing this. Once again, it is _viewer_, it's not supposed to _change_ files. > If you want to do that, hold two different files - > the original and the annotated - you will have the freedom. Nice. Should I give an example when having two copies of, say, some contract document can lead to unexpected results? :) > I really like this kind of fundamentalism. Everybody > knows the exact date when all possible formats will > have the same ability to store the same amount of > data (like annotations): NEVER Who cares about formats ability to store annotations? I can annotate _any_ format NOW (_exactly_ because of separate storage of document itself and private annotations), that's what matters. Just give some option to easily exchange this annotations and voila! And if you make embedded-in-the-doc annotations for PDF then suddenly one format behaves radically different from the others. What's so good about it in universal viewer? And, to repeat, I have nothing against that as long as it is _option_ and not default one. Don't get me wrong, I know it is requested, I do see the number of votes, and I'm _not_ shouting "kill this damn request, kill". I'm just trying to make some points that I think is relevant for discussion and that might affect app design considerations. After all, it's all up to developers to decide.
With the argumentation that a viewer can strictly be used for reading, you fulfill the paradigm of a specific software definition. the human being must therefore obey the paradigm of the tool which was actually created to help him... sound curious, ey? Design considerations should always be orientated on the needs of the users - and when pdf is going to replace a standard book - there is obviously need a comment function also on viewer programs.
> Design considerations should always be orientated on the needs of the users Sure as hell. That's exactly why I'm writing it all here. > there is obviously need a comment function also on viewer programs. Do you see any contradiction with my comments? I don't. There _is_ this feature in Okular. I have _nothing_ _against_ __commenting__ _documents_. I just don't want my comments to mess with the document itself, I want my private annotations to be separate from the document, just _as_ _it_ _is_ _now_ (and that works with _every_ supported format (well, except bug 168068 :))). There is just need to add support for sharing this comments, which _in PDF case_ can be done in embedded-in-the-file fashion. So big red button "embed my comments in the file" can do the job for PDF. Cool! So be it. Just don't change my files without this big red button (or big red checkbox in options if you think it's more appropriate).
@roman I understand that you don't want to change your original file but this problem can be solved different. In the settings you should be able to decide for yourself safe the annotations within the document or within a separate XML-file but I think that one should be able to put annotations IN the file if he or she wants to. And even if you put your annotations right in the document there should be a feature which lets you export both annotations and the document itself. Or the other way around somebody gives you an XML-file which you can import into a document.
I feel that some developers here are getting a little defensive because a huge amount of work would be necessary to implement all of this, and they don't want to do it. I'd say that they need to separate the concepts of what they are willing to do, and what ought to be done. It is clear that the annotation feature in Okular is broken. It does not do what any user would expect it to do. This obviously needs to be fixed. The huge amount of work involved in finding an alternative to poppler (for example), does not change that fact. KDE 4 development is very innovative, but sometimes forgets that (at a given point in time) it is better not to offer functionality than to offer it and disappoint.
And some users need to know they are not the center of the universe. Actually i have mails from users that say the current implementation rocks. Because they don't want their pdf to be modified at all. BTW And i'm not saying we should not allow saving annotations. We should allow it as an option. Saying to find and alternative to poppler shows you don't know anything about pdf. Summary: We need to support storing annotations in pdf documents -> YES It's a lot of works -> YES The current feature is useful to some people -> YES Patches are welcome -> YES And by the way bashing developers won't help you.
On Saturday 09 August 2008 11:25:54 am David Short wrote: > I feel that some developers here are getting a little defensive because a > huge amount of work would be necessary to implement all of this, and they > don't want to do it.
Just to add a note to what Albert and Brad already said: Okular will NOT change annotations in the document without your explicit action. That means, that (when Okular will gain the possibility) they will be changed when you do "Save as", just like right now you can change the values of form fields with that action.
@ comment #46 yes, i agree.. to alter documents without permission/notification would be bad.. but to make comments non-portable is a very big restiction (for me). i comment documents for other people, on other machines (platforms,...) my proposal: i think, a bla.pdf.okular-comments file next to the pdf would be a compromise as not-so-long-term solution. we would get partial portability (still bound to okular) and not-so-good transparency (extra-file next to the pdf). but still better than the current state with no portability at all
Created attachment 27349 [details] store annotations in a file named after the file's MD5 sum
(In reply to comment #9) > It'd be > great if rather than associating the annotations to filenames, okular could > install associate XML files with PDFs based on hashes (e.g., sha-1, md5, etc.) > of the PDF. I have a similar usage scenario in mind and did a quick hack to do just this (see comment #48). It works nicely in several ways: *) Annotations keep associated with the file after renaming it. *) It also works for non-local URLs (http://...) since we don't need to care for mapping the URL to some valid file name. *) Annotations keep associated with the file after downloading it from the web and opening a local copy (possibly under a different name). A cmake module to detect the mhash library (or complain if it's not available) should probably be written. BTW (to submit my vote :-), I very much like the idea of having separate files for storing annotations since this makes it possible to merge annotations from different people. Nevertheless, I would also love to see the option to store annotations directly in the file (at least for file formats which support this, such as PDF). Kind regards, Markus
Very nice idea Markus. Although you should probably try to use the QCryptographicHash class (that supports doing md4, md5 and sha1), instead of depending on an external library.
@Markus Grabner: Please do not hijack this bug with something else. This bug is about "storing the annotations with the document", not "changing the way the internal information is saved". If you have ideas, please join our mailing list (okular-devel), and start proposing them there. Thanks.
Created attachment 28329 [details] a perl script for saving annotations in local files.
I discovered okular today, and I find it extremely useful... if it could save annotations. I plan to use it for annotating slides during lessons and for sending notes to collaborators while editing articles. So, I wrote the quick perl hack (also attached to the discussion, I hope -- this is also my first bugzilla contribution). Save it as "oku", make it executable and use it. I choose to let annotation persist even if file changes: in general annotations may be scrambled (I would love to have them linked to text, rather than to physical coordinates) but for small changes during editing they may be still useful -- especially for notes. #!/usr/bin/perl =pod usage: oku [options] <file>\n"; copies the annotation file <file>.okular to the okular shared kde dir (where okular expects it), launch okular and after it exits, copies back the annotations. Notice that if file changes, annotations persist (probably scrambled). options: -x : do not copy the annotations (delete them) end_message =cut use Cwd 'abs_path'; use Getopt::Std; my %options=(); getopts("x",\%options); my $file = $ARGV[0]; print "--$file | $options{x} | @ARGV\n"; die "missing file" unless $file; my $okular = "$file.okular"; my $size = (stat($file))[7]; my $path = abs_path($file); my $xml = "$ENV{HOME}/.kde4/share/apps/okular/docdata/$size.$file.xml"; my $content; if (defined $options{x}) { print "deleting annotations\n"; } else { undef $/; open OKULAR, $okular; $content=<OKULAR>; close OKULAR; #q&d replacement $content =~ s/<documentInfo\s+url=".*?"\s*>/<documentInfo url="$path" >/s; print "writing okular data to $xml\n"; open OUT, ">$xml"; print OUT $content; close OUT; } `okular $file`; print "moving okular data to $okular\n"; `mv $xml $okular`;
Created attachment 28345 [details] improved version of oku script Thanks for the script, Franco. I have extended it a little bit. Now you can also call the script with the absolute path of an PDF file and it can handle spaces in filename and path.
I think this script is a good workaround until okular is doing this job. Just tell tell KDE to open PDF files with oku as default. Then your notes are always stored beside the PDF file.
SVN commit 884597 by pino: Add API to load and save "document archives", ie an .okular archive with document and metadata (currently annotations). Few missing to be done in it: - more checks when saving - make it use a proper mimetype CCBUG: 151614 M +201 -2 document.cpp M +14 -0 document.h M +5 -0 document_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=884597
SVN commit 884852 by pino: Expose to the world the document archiving functions: - loading: slightly edited the loading function to call the right open function of Document in case the file is a document archive (choosen normally in the "open" dialog) - saving: added an entry in the "export to" formats (and shuffled some code for being more flexible) probably not much ideal for an usability POV, but we can work on it. M +38 -4 part.cpp M +1 -0 part.h WebSVN link: http://websvn.kde.org/?view=rev&revision=884852
Hi guys, I read all of the comments. The result is that we can't save annotations directly to files. But I have an idea to create files which include user's annotations. The idea is simple: The tool renders annotations to show them in prints. In this way, we can use virtual printers which create pdf files (e.g. PDFCreator in Windows) from programs output. Therefore, we have annotated pdfs without any thinking about implementation of saving annotations beside our files. Is it a feasible idea to implement? Cheers, Habib Seifzadeh
@Habib Seifzadeh Yes, if okular could print documents with annotations that would be really great. You could redirect the output to a file and send it to everybody who has a PDF reader. That would be a real plus in term of compatibility. But IMO this solution should not be the default if you want to send a pdf with annotations to someone using okular too, because in that case he's not able to edit the annotations anymore. This problem can be solved by saving the annotations beside the document, as the oku script does. I'm currently satisfied with the oku script solution. I'm using it on all computers and have replaced the file association of ".pdf" to be always opened with oku instead of okular. Well, if okular would have an option to "store annotations beside documents", things would be easier, of cause :)
Printing annotations in a document is bug #159005. Beside that, Okular in KDE 4.2 has a function to create a document archive, ie a "pack" containing document + metadata. Reading of those "archives" is implicit, while creation is done via File -> Export. Ah, Stefan Endrullis, please do change the extension of the "metadata" saved by your script (that is no more useful with KDE 4.2, FYI), because .okular is used by Okular now.
Created attachment 28919 [details] improved version of oku script 2 Changed the extension for the "metadata" from .okular to .oku.
This bug seems to be mostly about how to bundle Okular's annotations with documents. Is there a separate bug report about supporting PDF annotations in a way that is compatible with other PDF readers, e.g. Adobe Reader, or should we open one? IMHO this would be a very much needed feature, even if the Okular-specific bundling implementation comes to pass. The main use case for "standard" PDF annotations is as a collaboration tool; I send you a draft of my document, you annotate it and send it back. This should of course work cross-platform and regardless of which PDF reader you and I are using. So, should we open a bug: "Support editing and saving annotations according to the PDF standard"? Or keep the whole discussion to this bug? http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf -- section 8.4
@Martin Rehn Such things have already been discussed in the comments above, see http://bugs.kde.org/show_bug.cgi?id=151614#c3 The problem is that the current architecture of okular does not allow changes to documents. Even the okular annotations can not be saved within the document. That's why the current solution is based on an export function. OK, there could be an export of the PDF with Adobe's annotations as well, but who is going to implement it? And is there a free and open specification of Adobe's annotations or is it just a proprietary extension of Adobe? I don't know.
Sorry, haven't seen your attachment. Then it seems there is a documentation about Adobes annotations. OK.
@Martin Rehn: based on your comment, there seems to be some misunderstanding of the situation on your side; probably you skipped all the comments at all? Can't say that. Let's go analysing the situation, again. > This bug seems to be mostly about how to bundle Okular's annotations with > documents. There is not bug at all, just a "custom" solution based on the fact that the library used by Okular to handle PDF documents - the Poppler library - does *not* support changing any detail of the annotations in a document. (While it supports, for example, editing the value of form fields.) > Is there a separate bug report about supporting PDF annotations in a > way that is compatible with other PDF readers, e.g. Adobe Reader, or should we > open one? If you want to open one, you want to report that for Poppler, not for Okular. (Not that the situation is not known to the Poppler developers anyway...) Keep also in mind that Poppler already supports PDF annotations, but in a "read-only" way (as I said). Once Poppler supports changing the annotations in a document somehow, then making use of that feature in Okular will not be a big deal (some of the code in a very basic way is sitting here for a while so far). > So, should we open a bug: "Support editing and saving annotations according to > the PDF standard"? Or keep the whole discussion to this bug? Note also this bug is about generic storing of annotations in documents, that means all the kind of documents Okular supports (thus not just PDF). This is why Okular saves annotations by default in its data directory. Just a final (due) note: we are not forgetting this problem at all. This problem is not trivial to solve, especially with low resources. Please don't put pressure on us, especially if you cannot contribute at all (if not by testing); this won't help us at all in solving the issue. Thanks again for the patience.
(In reply to comment #57) > SVN commit 884852 by pino: > > Expose to the world the document archiving functions Unfortunately the MIME types don't seem to be registering successfully. The file is recognized as zip even if I add the extension ".okular" and mime type through personal settings > file associations. It says "can not find a plugin which is able to handle the document being passed". Does zip have any headers which could be used to more accurately identify the new file type? Maybe I'm missing something: from the diffs, it doesn't look like there's a save functionality that replaces the ".xml" files when new comments are added; is this the case? I'm using 4.1.87 (2009-01-01) on opensuse 11.1. thanks so much.
(In reply to comment #66) > (In reply to comment #57) > > SVN commit 884852 by pino: > > > > Expose to the world the document archiving functions > > Unfortunately the MIME types don't seem to be registering successfully. The > file is recognized as zip even if I add the extension ".okular" and mime type > through personal settings > file associations. Do you see a application/vnd.kde.okular-archive MIME type in system settings -> file associations? If no, then it is a problem of your distro. > Maybe I'm missing something: from the diffs, it doesn't look like there's a > save functionality that replaces the ".xml" files when new comments are added; > is this the case? What do you mean? Loading a document archive does not touch the saved annotations locally, and saving a new archive copies in it all the local annotations of the document. For "saving a new archive" I mean that - for now - you have to save again an open archive using the export function.
(In reply to comment #67) > (In reply to comment #66) > > Unfortunately the MIME types don't seem to be registering successfully. The > > file is recognized as zip even if I add the extension ".okular" and mime type > > through personal settings > file associations. > > Do you see a application/vnd.kde.okular-archive MIME type in system settings -> > file associations? If no, then it is a problem of your distro. how do I correct it? The packages are in the unstable repo, so it's likely things aren't how they should be. I added the extension but the x/zip seems to have higher priority or something. another point is whether okular should be so sensitive to mime types. regardless, I don't see an option in the file open dialog box for document archive. > > Maybe I'm missing something: from the diffs, it doesn't look like there's a > > save functionality that replaces the ".xml" files when new comments are added; > > is this the case? > > What do you mean? > Loading a document archive does not touch the saved annotations locally, and > saving a new archive copies in it all the local annotations of the document. > For "saving a new archive" I mean that - for now - you have to save again an > open archive using the export function. Right, you have to use the export function. I think it should transparently replace the ~/.kde/.../___.xml files, or at least a "save" option should be added.
(In reply to comment #68) > (In reply to comment #67) > > (In reply to comment #66) > > > Unfortunately the MIME types don't seem to be registering successfully. The > > > file is recognized as zip even if I add the extension ".okular" and mime type > > > through personal settings > file associations. > > > > Do you see a application/vnd.kde.okular-archive MIME type in system settings -> > > file associations? If no, then it is a problem of your distro. > > how do I correct it? The packages are in the unstable repo, so it's likely > things aren't how they should be. I added the extension but the x/zip seems to > have higher priority or something. The best solution is telling the packagers. They know what should be done. > another point is whether okular should be so sensitive to mime types. > regardless, I don't see an option in the file open dialog box for document > archive. Because there is no mime type available. > > Loading a document archive does not touch the saved annotations locally, and > > saving a new archive copies in it all the local annotations of the document. > > For "saving a new archive" I mean that - for now - you have to save again an > > open archive using the export function. > > Right, you have to use the export function. > I think it should transparently replace the ~/.kde/.../___.xml files, No. The metadata loaded in the document archive are specific to the document in _that_ archive, not in any other document. > or at least a "save" option should be added. That's why I said "for now" above.
(In reply to comment #69) > > another point is whether okular should be so sensitive to mime types. typically, file formats have data stream identifiers which don't require file extensions to trigger a system mime type [in order to open the files], no? I thought zip archives had comment fields; maybe worth investigating. > > I think it should transparently replace the ~/.kde/.../___.xml files, > No. The metadata loaded in the document archive are specific to the document in > _that_ archive, not in any other document. I understand, I didn't mean all ~/.../.xml files. I meant that adding new annotation for a okular document archive should not generate new ~/.kde/.../.okular.xml files, but instead save it to the archive, if that hasn't been done already. Sorry I don't know what actually happens because it's not working on my system at the moment. regards, Nicholas
(In reply to comment #70) > (In reply to comment #69) > > > another point is whether okular should be so sensitive to mime types. > > typically, file formats have data stream identifiers which don't require file > extensions to trigger a system mime type [in order to open the files], no? This is basically recognizing a file format (= MIME type). > I meant that adding new annotation for a okular document archive should not generate new > ~/.kde/.../.okular.xml files, Of course, and this is what Okular does (not saving anything locally when opening a document archive). > but instead save it to the archive, if that hasn't been done already. As I said, this is currently done by explicitely exporting to a new document archive...
Hi, I've read more or less carefully all the comments ahead, would it be possible to print separatly the annotations and then to superpose the two pdfs, using pdf toolkit as : pdftk over.pdf background behind.pdf output superpose.pdf Regards C.B.C
Coudn't that be a great Google Summer of Code project? It would be really great to change PDF files (edit annotations, or even delete pages, change page order, ...)!
The consensus seems to be that saving annotations back into the PDF file is not possible, and that the solutions is to role a special .okular archive format which contains metadata and the original document. But what is not clear to me is why it is not possible to simply save annotations back into the original pdf? Both Foxit and Adobe Acrobat Pro can save annotations back into the original document, so it would seem to be possible from a technical standpoint. This also seems to be the better solution, as a .okular format will not be portable across PDF readers, and thus mostly defeats the point. I would highly encourage the developers to direct their efforts toward matching the functionality of other Foxit and Adobe Acrobat Pro in terms of being able to save annotations back to files. As it stand right now, I believe the user experience is frustrating and counterintuitive.
(In reply to comment #74) Sorry, my bad, I didn't read closely enough, and I see now that poppler doesn't support writing back into open PDF files. I stand by what I said about I the user experience being frustrating and counterintuitive, but I cannot offer any advice as to how to how to reach a better solution. For the moment, I'll have to continue using Foxit under wine.
*** Bug 188123 has been marked as a duplicate of this bug. ***
So, how is the status now? Can I save the pdf with the annotations or not? Why should I make annotations whithout being able to SOMEHOW save them? a) in an external/globally saved xml b) in the pdf itself c) in a copy of the pdf+annotations somewhere. I'm sorry but reading through the comments I have the feeling everybody tries to neglect, that this issue is far more than a whishlist-thing. It's a killer criterium! Now I have to make notes as a text document in the same folder as the pdf. So there is thrashing, anyway! Thanks for your consideration
Most important for me: How can I print the exported document archive .okular without losing the annotations? Because I lose them...
(In reply to comment #78) I mean text-highlights.
This bug is still open, so you should not expect that everything discussed is implemented. For the current state, you might like to review http://docs.kde.org/stable/en/kdegraphics/okular/annotations.html
Some years ago, there was possibility to sponsor some KDE program features to accelerate the implementation. Is there still a chance to do so? I think the implementation is pretty difficult, due to the complicated pdf standard and no one will spend much of his spare time to program it (me neither) However, now I'm forced to boot Mac OS X when I want to make annotations within the pdf document, but I'd like to stay on Linux.
@Harald: As an alternative to dual-booting, I've found that Foxit PDF Reader works great under Wine. I just wrote some instructions on how to set it up under Ubuntu: http://yetanotherjsblog.blogspot.com/2009/07/how-to-use-foxit-pdf-reader-30-on.html Good luck.
I also also gave it up to hope that okular will support annotations in a usable way in near future. So i also searched a lot for alternatives. First i found Foxit too. It does it's work, but the PDF-XCHANGE VIEWER runs as good in wine and you can do a lot more stuff for free and without marks on your PDF than with Foxit. At all it looks much more professionell. For me this is now the solution for this bug ;-) At all let's say: I understand that okular is an open source project. So no one can expect something from it. But i don't think that it is a good way the team does with annotations now. They play to the user that they can make annotations and when they try then to send theit pdf with annotations to a friend (what is normal for what you make annotations) the annotations are gone. In my opinion this is really unprofessionell and confusing for users! Such a behavior makes not only a bad picture of okular, no, also of kde. My suggestion would be to remove annotations until they work in a usable way or to make BIG and visible warnings that in the moment it don't does what the user is expecting.
Regarding the MD5sum patch to identify documents based on content instead of based on name, I recommend adding a method to kdelibs because other apps such as Palapeli from kdegames also have such functionality. It will break for modified files though, such as audio files with metadata and possibly modified PDF files in the future. A robust implementation hence requires some filetype-based logic instead of just MD5. Regarding the portability of annotations, I've just been directed to this bug while annotating a PDF for a student. In case the student has Okular, I can now pass around the .okular archive, or perhaps just the annotation .xml if the student knows what to do with it. If the student doesn't have and/or want Okular, and Okular will not save the annotations within the PDF, would it be easy to at least create a PDF from the annotations which can be printed as a list with page numbers? I'm thinking of maybe having some XSL which can output an HTML summary of the notes or through some QPrinter(?) transformation also PDF.
Created attachment 38042 [details] Annotations for mere human beings This script transforms annotations in .xml into .html so that they can be transmitted or printed in a human-friendly way.
*** Bug 216610 has been marked as a duplicate of this bug. ***
*** Bug 216611 has been marked as a duplicate of this bug. ***
(In reply to comment #85) > Created an attachment (id=38042) [details] > Annotations for mere human beings > > This script transforms annotations in .xml into .html so that they can be > transmitted or printed in a human-friendly way. Just to clarify how one is supposed to use that XSL, xsltproc okularannotations2html.xsl metadata.xml >out.html Whereas metadata.xml is the damned annotations file (either from your .kde dir or from the .okular zip). The resulting HTML is fairly retarded though, as it does not show anything better than page number and the annotation text. That said, I add myself to the crowd that wants proper and portable support for annotations in Okular. And I agree that the current behavior is counter-intuitive and frustrating.
I support this wish too. And why are we limiting ourselves by the base library and document types. If you can do it in PDF but not in DjVu then at least do it in PDF, warn if else and convert the document to PDF. Just renaming or moving the files make the annotations disappear and I can't be sure that my friends are using okular every time. They use GNOME or even Foxit. It may happen that someday due to a bad command or some hardisk crash I may loose my home directory then the tedious work of making inline notes would be lost. This is seriously important wish. You may give the options to the user that they may use the .xml vs in-file editing. On the other hand the .xml files (or some file in the same directory) may be helpful to view the documents without annotations. If the file or the directory is not writable we may give the user the choice to store file somewhere else like the home directory.
*** Bug 223266 has been marked as a duplicate of this bug. ***
*** Bug 226079 has been marked as a duplicate of this bug. ***
I know that are some hard limitations that don't allow Okular developers include this feature at this moment, but I think that this a very important feature, that deserves more attention, even changes in backend modules, if nececessary, etc. But, even if this definitely won't be included, the export of annotations to html or a text file would be a helpful feature.
I checked the software PDF-XCHANGE viewer. It allows to save annotations, later selectively delete them too, means annotations are not saved as hardcoded but separately. Also it allows to hide/show selective annotations. When I open the file in Okular I find that (at least popup note annotation) is there and in fact in a nicer way than Okular built-in. Highlight though was shown in the document there was no mention of it in annotaions sidebar list. So this really rubbishes out the viewpoint of Okular devs that Okular doesn't do or its non-standard, for they are at least reading the annotations saved with the file. Now its upto them to do this change. Good reasons to do: 1. I want the annotations to go accross programs. My friends, teacher, boss may use GNOME, xpdf or any other program and I don't want to give them .okular file, this is ridiculous to ask them to install KDE when they have a GPLed software stack already (competition is there is FOSS eh! but you need to support the options). 2. Maintaining the .xml files and to take care about the renames made is tedious. 3. Also if you are storing the annotations in separate .xml file, goto point 1.
I share your opinion. It would be better to have no annotations than annotations which are not standard, like it is in the moment. This is one of the main reasons why i don't like windows... because they don't care about standards. We should not do the same in linux.
[http://en.wikipedia.org/wiki/Pdf#Annotating_PDFs] has something to say. [http://en.wikipedia.org/wiki/PDF/A] this article says that annotations are there to be in the proposed 1.7 standard and I found that they are a part of it since Adode Reader 6.0 [http://en.wikipedia.org/wiki/Adobe_Acrobat#Version_6.0] I don't think that they are very uncoventional, since almost every feature rich pdf reader has them. Sometimes we need to consider the standards as in accpetable by all rather than as in a stamped documnent by a body (who calls Javascript EMCAscript?)
You misunderstood me. I only said, that it would be better to have no annotations than annotations like they are realized in the moment! Because in the moment the annotations are not added in the pdf standard, but okular pretends the user that it does... This is very unprofessional!! This is not what i expect from a linux software.
However there are annotations added by other software to the PDF files that are read by Okular. So Okular supports both allows its users to do only one? Ok here is what I found and it says that annotations are the part of the PDF 1.7 [http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf] Please do read. Its a doucument published in November 2004 (as given in Preface) Also annotations described in PDF 1.6 [http://www.adobe.com/devnet/pdf/pdfs/PDFReference16.pdf]
Guys, this feature is open for 3 YEARS and has 588 or so votes which places it into the 50 most wanted features. So there is an obvious question WHATS THE HOLD UP?
I would certainly welcome an official answer too. As I have been following this report for a long time I think there are two issues. (I right now have no time to find the sources for this, sorry) 1. libpoppler was created with the intention of a readonly library therefore it does not support writing back to the pdf stream. The architecture is not well suited for that. There is another pdf library being developed, but in very early stages which should remedy this issue. I forgot the name, but I think it is even sposored by the FSF. 2. The okular developers are satisfied enough with the situation as it is today. As they do it in their spare time they do not want to spend too much time on this. I have read at several places that people are willing to spent money on this to get it working, but as far as I know there has been no coordinated effort yet. And offered to do the necessary programming.
I have seen those arguments too, but ... > 1. libpoppler was created with the intention of a readonly library therefore it > does not support writing back to the pdf stream. *input* library has nothing to do with *output* library. "Print to PDF" works for many years already, so "copy to PDF and add annotations" might be an easy enough task to do, even if it was outside poppler. (The separation might even be positive.) > 2. The okular developers are satisfied enough with the situation as it is > today. As they do it in their spare time they do not want to spend too much > time on this. Spare time service does not imply unprofessional or lousy although the current status quo does seem that way. It would be at least nice to see some priority list of the bugs to know how far in the queue we are. Besides that I think there *are* paid people who contribute to okular and KDE in general.
(In reply to comment #101) > Spare time service does not imply unprofessional or lousy although the current > status quo does seem that way. It would be at least nice to see some priority > list of the bugs to know how far in the queue we are. > > Besides that I think there *are* paid people who contribute to okular and KDE > in general. I think the same. Spare time service would legitimate to implement _no_ PDF annotation. But in the moment there is a PDF annotation which is highly unprofessional misguiding for users. As i suggest since a long time: If you are not able to implement Annotation like in the PDF standard, then don't allow users to make notes or pop up a _big_ warning message! The way it is implemented in the moment is a shame for KDE.
(In reply to comment #101) > I have seen those arguments too, but ... > > > 1. libpoppler was created with the intention of a readonly library therefore it > > does not support writing back to the pdf stream. > > *input* library has nothing to do with *output* library. "Print to PDF" works > for many years already, so "copy to PDF and add annotations" might be an easy > enough task to do, even if it was outside poppler. (The separation might even > be positive.) No, it is not. > > > 2. The okular developers are satisfied enough with the situation as it is > > today. As they do it in their spare time they do not want to spend too much > > time on this. > > Spare time service does not imply unprofessional or lousy although the current > status quo does seem that way. It would be at least nice to see some priority > list of the bugs to know how far in the queue we are. So show us the code. > > Besides that I think there *are* paid people who contribute to okular and KDE > in general. Thanks. This is exactly the kind of poison which made two developers (including a maintainer) to leave the project. If this is your contribution to the discussion (where you missed some point to say the least) please refrain from doing it again.
(In reply to comment #103) > (In reply to comment #101) > > I have seen those arguments too, but ... > > > > > 1. libpoppler was created with the intention of a readonly library therefore it > > > does not support writing back to the pdf stream. > > > > *input* library has nothing to do with *output* library. "Print to PDF" works > > for many years already, so "copy to PDF and add annotations" might be an easy > > enough task to do, even if it was outside poppler. (The separation might even > > be positive.) > No, it is not. Why not? Dividing jobs among several programs/libraries to create more complex functionality is quite common in Unix environments and for good reasons. > > > 2. The okular developers are satisfied enough with the situation as it is > > > today. As they do it in their spare time they do not want to spend too much > > > time on this. > > > > Spare time service does not imply unprofessional or lousy although the current > > status quo does seem that way. It would be at least nice to see some priority > > list of the bugs to know how far in the queue we are. > So show us the code. What's that got to do with anything? > > Besides that I think there *are* paid people who contribute to okular and KDE > > in general. > Thanks. This is exactly the kind of poison which made two developers (including > a maintainer) to leave the project. If this is your contribution to the > discussion (where you missed some point to say the least) please refrain from > doing it again. What crept up *your* pants? Why do you even bother to post, when you have nothing useful to contribute? This is exactly the kind of poison... (well, I guess you know the rest)
> WHATS THE HOLD UP? The situation is still the same: missing annotation editing support in poppler. > I would certainly welcome an official answer too. Like the ones that have been said for years? For example, comments #21, #44, and #65. > > 1. libpoppler was created with the intention of a readonly library therefore it > > does not support writing back to the pdf stream. > > *input* library has nothing to do with *output* library. "Print to PDF" works > for many years already, so "copy to PDF and add annotations" might be an easy > enough task to do, even if it was outside poppler. (The separation might even > be positive.) poppler's architecture can, and is being (slowly) changed, but the main job is missing. > There is another pdf library being developed, but in very > early stages which should remedy this issue. I forgot the name, but I think it > is even sposored by the FSF. gnupdf? It does not even have a lexer for reading the PDF format from a file... (and thus not read a document) Some might (or already did) also refer to podofo. There are various problems of using two libraries for PDF files, like: - different ways of reading the document (thus potential different results) - two implementations which own bugs to deal with - different kind of support of the PDF format in each of them and so on... in short: you get, potentially, the advantanges of two libraries, but also the problems of two different libraries at once. > 2. The okular developers are satisfied enough with the situation as it is > today. As they do it in their spare time they do not want to spend too much > time on this. Oh please... > And offered to do the necessary programming. I have seen so far nobody (who isn't a poppler developer already) providing any kind of work for annotation-related tasks.
> The situation is still the same: missing annotation editing support in poppler. So why are you so insistent on that particular library. Suppose poppler can't do that and won't do that. Then it's just the same as waiting for the linux kernel to have it implemented. What are the other options? > > I would certainly welcome an official answer too. > > Like the ones that have been said for years? For example, comments #21, #44, > and #65. Well, one of the usual bullshit responses among those suggests that this is not really your problem but it's with poppler so we should go ASK THEM (tm). But I as a user don't really care if your problem lies in poppler or double whopper or whatever. I use your program, not the library. You use the library, you know what to ask them for. Why do you expect us the users to know better than you, and why do you expect us to do your job (integrating the library) for you? And about the "has been said for years". I admire your patience. I really do, because if I was in your shoes I would just code the thing instead of takling for years about how it can't be done. And maybe if this issue goes for another couple of years I'll just do it for you. > poppler's architecture can, and is being (slowly) changed, but the main job is > missing. In the meantime we are kindly asked to use another PDF product. > in short: you get, potentially, the advantanges of two libraries, > but also the problems of two different libraries at once. Let's try it and see which one it was? > I have seen so far nobody (who isn't a poppler developer already) providing any > kind of work for annotation-related tasks. That's unfortunately how it's gonna be. Not every Okular user is a hacker and even if he is he might not be interested in the learning curve associated with hacking Okular. Remember there is a lot of other broken software out there.
(In reply to comment #105) > > WHATS THE HOLD UP? > > The situation is still the same: missing annotation editing support in poppler. This is no reason for the fact that annotations are implemented in the moment in an unprofessional and misguiding way.
(In reply to comment #106) > > The situation is still the same: missing annotation editing support in poppler. > > So why are you so insistent on that particular library. Well, if we look at the parts you so generously snipped, we'll notice that he listed alternatives and reasons why they aren't usable (well, sort of, anyway). > > in short: you get, potentially, the advantanges of two libraries, > > but also the problems of two different libraries at once. > > Let's try it and see which one it was? That isn't an alternative. You will *definitely* get the disadvantages (incompatible data structures, to name just one), but you only get the advantages if you're lucky - andvantages that outweigh the disadvantages, that is... > > I have seen so far nobody (who isn't a poppler developer already) providing any > > kind of work for annotation-related tasks. > > That's unfortunately how it's gonna be. Not every Okular user is a hacker and > even if he is he might not be interested in the learning curve associated with > hacking Okular. Remember there is a lot of other broken software out there. So? At least Okular is providing something with what little resources it's got. If you'd like to contribute some, go ahead. Otherwise show some gratitude for the fine work being done here or take your bitching to some forum. This is a bugreport and not a general discussion platform. Just to have said it: I once had to work on parsing a PDF stream and am rather glad that part of my life is over! You don't just add a whole new set of functionality to a library within a couple of days/months if that means changing its architecture. Especially if it concerns a "standard" like PDF with so many variations and buggy documents floating around. Be glad they found a way to read most documents, even a lot of the buggy ones. Writing back to them is another matter entirely.
Short Official answer from KPDF, Okular and Poppler maintainer: * Stop complaining Long Official answer from KPDF, Okular and Poppler maintainer: * PDF handling is hard * Any coding help is always welcome * Stop commenting about non Okular on this bug, specially if you want to suggest non free PDF viewers, do it on your blog * No, we are not happy with how annotation is now * We have lives to live, and this being hard to solve makes it slow to implement * Did i say we accept code? * None of us gets any money from doing KDE, Okular or poppler coding * There is lots of people there that are happy to have this "half" feature, so there is no way it is going to be removed, ever * Complaining again in a bug with 108 comments and saying "it is a shame and that we are unprofessional" will get you nothing, we all knew the situation before even this bug was created, people bashing us *yet again* do not help things gets done, it only helps us losing time having to explain the situation *yet again* * And yes, next time anyone writes a comment in this mail, think twice, three times or even put some sleep in between to make sure it adds something of value to the conversation, since reading the 108 comments, very few do achive it * Oh, and btw i almost forgot, we accept patches, if you are interested in contributing there is a okular mailing list you probably want to join
... or if I may add, if you're not happy about the current situation and cannot help with coding, hire a developer, start a fund rising on kickstarter, but stop whining like that. Which makes me think, it's a little bit late for today, but maybe that would be a good candidate job for a GSOC? Those with x86 machines can also use a little trick I use myself - you'll need wine and some kind of proprietary software, it's not as fast/cool as Okular, but it will do the job until good annotation support is implemented: http://www.gnurou.org/blog/2008/09/09/finally_real_pdf_annotating_under_linux
*** Bug 245251 has been marked as a duplicate of this bug. ***
All people looking at this bug might be interested in <https://bugzilla.gnome.org/show_bug.cgi?id=168304> which is the Evince bug for annotations. Evince in git is now starting to support annotations.
The feature is in Poppler-git now? Great news, that means support in Okular is just a matter of weeks (if any developer is interested in this)
Any developer interested is the only thing we ever needed, there's no difference between one month and now.
*** Bug 259590 has been marked as a duplicate of this bug. ***
Just a thought: how about storing the annotations with Nepomuk? It wouldn't help much with exporting but might help with problems regarding filename changes etc. because I'd expect Nepomuk to be able to cope with them. Anyway, everyone uses Nepomuk today for storing metadata so it'd be logical for Okular to follow the direction. Btw, I'm quite disappointed seeing all the comments bashing the developers. Shame on you people!
(In reply to comment #116) As far as I know the informations stored with nepomuk only keep alive, if you use for copy/move an application which supports nepomuk (e.g. dolphin)
(In reply to comment #117) It seems to be so at the moment: http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/FileWatchService but let's hope someone will develop a proper file watching system, as this problem affects all metadata!
Evince already supports annotations (stored in pdf-file). Look here http://carlosgc.linups.org/2010/Jul There is also a note in the changelog of poppler-0.13.2 [...] * Add support for Screen annotations [...] http://poppler.freedesktop.org/releases.html So it should be also possible to implement it in Okular.
its extreamly annoying when all notations are lost by moving a file. maybe okular should use nepomuk to know when a file was moved. sometimes ago I got a pdf file from a friend witch was created or edited in mac os. his notations was included in the pdf document, because I could see his notations and he only send the pdf file to me. :-/
(In reply to comment #120) > its extreamly annoying when all notations are lost by moving a file. maybe > okular should use nepomuk to know when a file was moved. [...] Okular seems to have already the possibility to recordnize pdf's which were moved on the own system. Why nepomuk is no solution look at comment 118 & 119. PDF is a standard exchange format. Thats why annotations have to work OS-unindependent.
As not only "full featured" PDF viewers/editors have an annotation feature by now but also Adobes Reader in its current version this is getting more and more a "must have". It would be really nice if someone would take a heart and implemented this some time :-)
Unfortunately Adobe Reader X is not available for Linux. It's so sad still not having an annotation tool for Linux after many years.
Obviously the feature is not attractive enough for itself to be implemented by a developer. How about set up a monetary incentive through sites like http://www.bidforfix.com or any other site the developers choose? There are enough people who want this feature and might be happy to support the implementation by a few bucks, euros... Just an idea.
I just made a great discovery. http://www.mendeley.com/ is able to annotate PDFs without an issue so far. You can download it at http://www.mendeley.com/download-mendeley-desktop/ It is written with Qt.
I respect #109 therefore only a short comment on #125 Last time I tested mendeley it wasn't that great: * Existing annotations were not displayed * Annotations are not automatically saved in the pdf, you must export the pdf * Annotations does not have the user id (or a user name) * PDF Viewer does not display the bookmarks * and PDF rendering wasn't that good like in okular
Mendeley is neither open source nor is it "just a simple PDF viewer". But it seems to be a pretty nice piece of software, although I can confirm comment #126. So I guess each of you have to see if it fits your needs. Thank you for the hint.
Has anyone tried Xournal, http://xournal.sourceforge.net/. It seems to be able to annotate pdf files, and acrobat seems to read without issues.
(In reply to #128) Xournal uses a trick: it loads PDF file as background for its journals (using poppler library). You can export the data as PDF, but you'll get the original PDF as background and the annotations as graphics over the background. So: - You can't search or copy text and other text related opearations as long as there's no text, original PDF is now a background image. - There's no info about the annotations, they are just images, so no popup notes, user info, etc. So Xournal doesn't really annotate PDFs, just used a trick to simulate it. There's no chance to use Xournal code to implement PDF annotations. See Xournal manual, "PDF Annotate" section: http://xournal.sourceforge.net/manual.html#pdfannotate
Hi, I think it's really not the right place here to discuss alternative pdf viewers. But if you are looking for a free, working solution for annotations use the latest version of evince, it has working annotations. Else, please stick with the discussion here ontopic, that is the implementation of annotations within okular, not any other piece of software.
I think one of the reasons this is one of the most hated bugs is that initially for the user it looks like this is a useful feature, then he spends hours using it before noticing that there is no way to get the annotations either printed or exported in a format usable by anybody else. I just spent an hour reviewing a document and making tens of annotations to it. "Oh, Okular has an annotation feature, how nice". Now I learn that that was entirely wasted effort and I need to type all those same things separately into email. How annoying. Really, if you cannot consider adding a suitable warning before someone uses the annotation features, I would very much have preferred there being no annotation features at all compared to this. Now it's misleading and leads to hours of wasted effort.
I am completely with you Sami and posted this before more then one year. No one can estimate an open source software to have a special feature. But an open source software which pretends to have a special feature an makes damage to someones work with this is bull shit. A simple warning message would be less work, than they make for every single person which fall for this. In my eyes they wanted to pretend strong features, which okular not really has drawn to pdf support. Why I let open for everyone.
The same thing happened to me. I assumed that annotations meant standard pdf annotations.
The same thing was that bugged me most. After having annotated so many files, I found that they were stored separately and non-portable.
I agree the last postings compleatley (since 131, maybe before) I have the same problem. My 'workaround' for now is, to sync the ocular folder in .kde between my pc's. AND I HOPE THAT THE DEVELOPERS SOMETIMES WILL READ THAT BUGREPORTS. It does not really seems so, yet, sorry. That report is now open for such a long time. Discussion seems endless. That could be one of the great featuers to satisfy people from linux and kde. :-/
@135: We do read bug reports, but when we get acused of doing things wrong on purpose and people say things like "Why I let open for everyone" implying we have some sort of evil hidden agenda, we really don't get a morale boost to work on this particular issue. OTOH you might want to use the .okular file format (by using File->Export As->Document Archive) instead syncing your .kde folders.
@136: Tell me one reason why it is not possible to implement a simple warning message in over 3 years users having severe troubles with this issue?
(In reply to comment #137) > @136: Tell me one reason why it is not possible to implement a simple warning > message in over 3 years users having severe troubles with this issue? This is not a commercial product where you pay developers to implement whatever you wish. If you want it to be done - patches are welcome - it's OpenSource. I surely wish the situation to be resolved, too - but acting like this doesn't help here anyone.
@137: It is clearly documented in Okular documentation http://docs.kde.org/stable/en/kdegraphics/okular/annotations.html (also easily accessible by pressing F1 in a running okular)
You don't expect people to read a manual to use a PDF reader, do you? Especially if it seems straightforward enough to use. Generally it's a good idea to warn before doing something destructive; why not apply the same principle to a case where the user is likely to waste hours of their time? You do see that the feature is not very useful currently, don't you, and that it's very misleading?
@140: The feature might not be useful to you, it is useful to others, just those others are not as noisy as you because they are happy using it. And we never said we saved the annotations to the file, so i don't see the misleading-ness.
Eh, I'm not quite alone here as you may see. The mere Cc: list here proves the misleadingness of this. I'm not arguing it's useless, but in the current form it's likely to cause very many people to waste hours annotating documents before they notice there's no way to share those annotations to people not using Okular. Really, it sounds like you just try to justify the current state of things, no matter what. Can you at least consider the possibility that the lengthy Cc: list consists of people who have wasted lots of time because of this, and that this could be fixed by a simple warning?
A simple warning will fix nothing, what we need is the hability to save the annotations in the pdf file. Now stop wasting my time.
How ironic. Stop wasting your time. Indeed. A warning would prevent Okular from wasting the time of hundreds of other people. Of course everybody agrees the ability to save the annotations to a PDF file would be even better, but it's rather ridiculous that you cannot see how the current state is worse than nothing.
If a user uses PDF annotations he expects them to be PDF standard conform. In my eyes it would be better to have no annotations than annotations which are not standard conform, because such things are Microsoft jobs and I don't want to see them in linux. But if you think that this feature is that great that it should be there the least would be to warn the users. In my eyes it is, like I wrote... it was only important to say "Okular supports PDF annotations" and not that it really does it. The reaction here supports this suggestion.
Timmorn: I disagree, it doesn't look like that to me. The annotations *are* a useful feature, even if in a quite limited way; the only problem with that is that any user would naturally expect to be able to share them with others (not using Okular), and will be quite annoyed after spending hours annotating some document. Of course there cannot be serious disagreement that better annotation support would be even better, but even rudimentary non-misleading support can be useful.
This is a rather polemical (non PDF standard) feature and this discussion is causing friction between users and developers. So my suggestion is a simple dialog box on the first time one uses Okular's annotations that warns the user that the annotations are not PDF standard but rather an Okular only feature, and a check box so the warning never shows up again. I don't know how to implement it, but it seems a simple "fix" to keep everyone happy while PDF standard annotations are not implemented. And yes, no annotations are worse than having them, but the user should know that they are not PDF standard if one is trying to annotate a PDF, is somewhat misleading. On the other hand, users should take it easy on developers and try to focus on how to fix things rather than complain about it without bringing more confusion. Another suggestion is to try to enforce this feature to enter initiatives like Google Summer of Code (I bet you're trying to do this already), etc., as this must be one of the most wanted (if not the most wanted) feature in Okular for what I've been seeing. Or am I wrong?
As I see it, the the various commenters here apparently have at least three different kinds of problems: 1) Some dislike the fact that the annotations are "not standard PDF annotations"; 2) Some have a problem with the fact that there is no way to export (or print) a document with these annotations so that anyone else not using Okular can see them; 3) Some (like me) have a problem with the fact that there is no indication in the UI that the features in (1) and/or (2) are not supported. It's quite annoying to discover *after* annotating a 100-page document that there's essentially no way beyond screenshots to show it to the person you are annotating it for. Now of course everyone (including me) would prefer the world to be perfect and Okular to have every possible feature, but in the meantime I think a mere warning could fix (3), which I think is the only one of these that makes to anyone supporting annotations actually worse than not supporting them.
(In reply to comment #148) > As I see it, the the various commenters here apparently have at least three > different kinds of problems: > [...] > 3) Some (like me) have a problem with the fact that there is no indication in > the UI that the features in (1) and/or (2) are not supported. It's quite > annoying to discover *after* annotating a 100-page document that there's > essentially no way beyond screenshots to show it to the person you are > annotating it for. I created a new bug report for that, please comment there: https://bugs.kde.org/show_bug.cgi?id=268575
*** Bug 268976 has been marked as a duplicate of this bug. ***
I have a question to the developers: 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.
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)
There is a GSOC project for implementing editing/saving of pdf annotations in okular properly (i.e. via the poppler backend, see http://socghop.appspot.com/gsoc/project/google/gsoc2011/petrmej/14001).
(In reply to comment #154) > There is a GSOC project for implementing editing/saving of pdf annotations in > okular properly (i.e. via the poppler backend, see > http://socghop.appspot.com/gsoc/project/google/gsoc2011/petrmej/14001). Best news since a long time! Maybe we get the results in autumn.
This is funny: https://bugs.freedesktop.org/show_bug.cgi?id=20193
> This is funny: > https://bugs.freedesktop.org/show_bug.cgi?id=20193 > I think that Poppler does not support some of the Okular annotations such as highlighting. Gnome's Evinc uses the term "annotations" only to mean text notes in PDF files, which _may_ be how the Poppler devs use the term as well.
answer from Albert Astals Cid about the status of the GSOC project: "The student did not produce anything of value". So there will no feature for storing annotations in pdf in next time.
(In reply to comment #157) > > This is funny: > > https://bugs.freedesktop.org/show_bug.cgi?id=20193 > > > > I think that Poppler does not support some of the Okular annotations such as > highlighting. Gnome's Evinc uses the term "annotations" only to mean text notes > in PDF files, which _may_ be how the Poppler devs use the term as well. According to http://people.freedesktop.org/~aacid/docs/qt4/classPoppler_1_1Annotation.html poppler has highlight annotations which "represents some areas of text being "highlighted"". And poppler can save annotations (cf. https://bugs.freedesktop.org/show_bug.cgi?id=20193#c2). I really hope that okular will be able to handle pdf annotations according to PDF specifications, it would fill a great need in floss softwares, and make okular an even better soft!
Which is the status of this features request? I am not a C/C++ developer...I would like to see in okular the possibility to choose to save my annotation in pdf file follow the pdf to share my annotation with other users (not only okular users). Thank you
Storing Annotations in the pdf dokument is one of the most missing features for kde. I am using wine and pdf xchange viewer as workaround. Please make it a top priority! Any news about progress? Any way to support the development? Iam willing to donate some money if someone works on it.
The feature to annotate pdfs in kde is sorely needed. I would also be willing to contribute some money to a project implementing this feature. Can anyone provide technical information about why this feature is hard to implement?
This feature is listed as "in progress" at KDE 4.9 feature plan. Hurray finally.
Does anybody know what approach the current work (feature plan) has for storing the annotations? Are there extra files in the same folder or are they embedded in the documents (at least for pdf)?
(In reply to comment #164) > Does anybody know what approach the current work (feature plan) has for > storing the annotations? It's already available in 4.9 beta 1 (poppler 0.20 is required). > Are there extra files in the same folder or are they embedded in the > documents (at least for pdf)? User annotations are still automatically saved in Okular's internal folders as usual (*). But now, if you press File -> Save As (it's availabe with PDF files only **), annotations are embedded in the saved document too (ie you can see/edit them in other readers). It's now also possible to edit existing embedded annotations. For other formats (and PDF itself), there's still the option to export annotatated documents in .okular format (File -> Export As -> Document Archive) and share them with other Okular users. * = Actually, automatic internal storage is disabled in some cases, and you need to save to PDF every time you make a change. But there are warnings and a "Save or discard changes?" prompt in place for that. ** = Poppler, the library we use to deal with PDF files, doesn't support modifying encrypted PDF files yet. If you open such a file, the "Save As" menu entry is grayed out and you are warned that you can only export as .okular file.
finally.. this is great! thanks for the work!
(In reply to comment #165) > User annotations are still automatically saved in Okular's internal folders > as usual > […] > Actually, automatic internal storage is disabled in some cases, and you > need to save to PDF every time you make a change. But there are warnings and > a "Save or discard changes?" prompt in place for that. i’m not exactly sure what that means: are annotations *mostly* saved into the pdf, or are they never implicitly saved or what? most importantly: is there a way to configure okular to automatically save them into the PDF, no matter if automatically after each change, or via prompt before closing okular in case changes were made. what i want is to completely turn off the old behavior and save each and all annotations into the documents, without having to choose “save as” from a menu each time i make some annotations.
(In reply to comment #167) > i’m not exactly sure what that means: are annotations *mostly* saved into > the pdf, or are they never implicitly saved or what? Short answer: They're never implicitly saved to PDF. They're still implicitly saved internally as usual, with one exception, in which case you'll be warned. Long answer: Annotations are never implicitly saved to PDF. In other words, the files you open are never automatically modified. You're have to explicitly press either "Save As" or "Export As -> Document Archive" in order to export them. We still autosave annotations internally as usual, unless the PDF document contains existing embedded annotations and it's not encrypted. In this case, you'll be shown a warning ("Your annotation changes will not be saved automatically. Use File -> Save As... or your changes will be lost once the document is closed") and a "Do you want to save your annotation changes or discard them?" prompt on document close. > most importantly: is there a way to configure okular to automatically save > them into the PDF, no matter if automatically after each change, or via > prompt before closing okular in case changes were made. No. You always have to go through Save As to get an annotated PDF.
hmm… i’m ok with this behavior as long as the "Do you want to save your annotation changes or discard them?" prompt allows a “yes, save them now into the document, then close” and i’d be also ok if ctrl+s would automatically overwrite the original document with the one containing the changes. if i’m reqired to click more than once to get the changes into the document, i consider this a hassle and thus a bug (this shouldn’t sound harsh. i’m excited about the functionality, i just don’t want it to require more interaction than i’m accustomed to) any reason why there is no checkbox “always save them into the document on close”? and why are they still implicitly saved outside of the document? will we end up with two kinds of indistingushable annotations in one document?
(In reply to comment #169) > and why are they still implicitly saved outside of the document? will we end > up with two kinds of indistingushable annotations in one document? No, it can't happen. That's the reason why, if the document already contains existing annotations, Okular won't save annotation changes internally and will ask you to explicitly save changes to PDF on close. In other words, either all annotations are saved in okular's local data directory, or all annotations are saved in the PDF file. Actually, encrypted PDFs are an exception to this rule: since they cannot be modified by Poppler at the moment (Save As is grayed out), you can't edit existing annotations in such files. New annotations are always saved in okular's local data directory and, yes, in this case you'll see both embedded and local annotations in the same document. But you can distinguish them: the embedded ones are read-only. > any reason why there is no checkbox “always save them into the document on > close”? It's obviously a useful feature. Please open a new wish for it. I'm closing this bug because: - for unencrypted PDF files: Since 4.9, there is support for storing annotations in the PDF itself. - for other file types: There's the .okular format (see comment #56) to store the document and the annotations in the same file. Please open separate bugs about the missing annotation saving features you (don't) find :) Thanks to all of you for caring about Okular
Thank you for implementing this
(In reply to comment #170) > > any reason why there is no checkbox “always save them into the document on > > close”? > It's obviously a useful feature. Please open a new wish for it. done! it’s bug 301774
i tried out the feature today and i like to thank you for making this change happen! technicaliy it works flawless for me. I would like to criticise the gui experience of this feature. It is totaly unintuitive that you have to do "save as" for storing annotations. i could understand that the file should not be modified without an extra save action, but why isnt there a simple save option? An example: when i like to add a comment to a new pdf i have to click "save as", than "save" (in the file selction dialog) and confirm the override waning. some time later i try to modify something. That leads to the question if i like to store the annotations. Again there is no "save", but only "save as". At this point it is getting totally unintuitive. I have never seen such a dialog before whith only save as and no simple save as confirmation. So it aks me if i like to save the annotations, i select "save as", than "save" in the file selection dialog, again confirm the overwriting of the file. This is unnescesary confusing. simply introduce save and everything will be much more consistent. This makes me feel like always working with write protected files. The many hints in the form of dialogs that appear to explain the behaviour to the user, are a symptom of not consistent workflow. would be nice to see this corrected. Then this feature is awsome and very usable. i dont know if this is the right place for crtisism, shoul i place it in a new bug or in bug #301774?
Yes, Till, your feedback is relevant to bug #301774. Thanks.
I updated by kde to 4.9 with kubuntu backport packages. Okular is now at version 0.15. However, the feature you describe does not seem to work. When I make annotations and try "save as" I get a message saying that my annotations will not be saved and I have to export as document archive. My pdf is unencrypted (created by pdflatex). Could this be a packaging error (compiled with wrong options, outdated libpoppler)?
check if poppler is at least at version 0.20. I had the same issue with poppler 0.18.
Ok poppler is still at version 0.18 in ubuntu 12.04. I temporarily upgraded to okular, poppler and depedning packages from kubuntu 12.10 (in development). This seems to work. I will create a bug-report at launchpad, although I don't think that the Kubuntu-team is willing to backport poppler. Thanks for the quick response.
@della kde backports ppa now has poppler at 0.20 and Okular at 0.16. It works perfectly. Thank you.
*** Removed by KDE Sysadmin for violation of the KDE Community Code of Conduct ***