Summary: | Okular should display a warning about before annotating | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Mihai C. <mihai> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | aacid, bugs, domlyons, fabiodurso, hhielscher, krichter, null, sami.liedes, stefano.cavallari, toddrme2178, wassipaul |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Mihai C.
2011-03-15 17:49:04 UTC
I wasted a lot of time annotating a pdf document, even sent it to somebody, before finding out that the annotations are not only not compatible with any other pdf program, but aren't even stored in the document. It seems I am not the only one who has had this problem. So I think a warning is definitely called for. I think the principle of least surprise comes into play here. When you have a program that, for the most part, conforms to the standard pdf behavior, and has one feature that uses the same name as a standard pdf feature, but that one feature behaves completely different than the standard version, I think users are justified in being surprised. Let me remind you that Okular is not a "PDF Reader". This is a wish, not a bug. Since you are the one requesting the feature, i expect you to provide a text for it. Using HTML-like markup: <text> <em>Warning: this is an Okular-specific feature!</em><br> Other programs will not be able to display these annotations and they cannot be exported to formats other programs are able to display.<br> Annotations are also not included in printouts. </text> Wishlist as in "I wish it just didn't throw my work that took hours to do away without warning"? Wishing as i wish my users where not trolls. Your work is not trown away, wathever you typed it is still there, and the documentation clearly states the behaviour. I'm sorry, I seriously don't think I'm trolling. I save the PDF with "Save As" - there's no warning. I close Okular - there's no warning, and the work is gone. What does astound me is the attitude that everyone who has lost hours worth of work because of this are "trolling"... And apparently any surprising and destructive behavior is OK as long as it's mentioned in the documentation?? There is no destruction done. Nothing is lost. It is just not saved where you wanted. There is no destruction done. Nothing is lost. It is just not saved where you wanted. In that case I apologize and stand corrected. Where is it saved and why does Okular not show the annotations when I reopen the same PDF? They are saved in `kde4-config --localprefix`/share/apps/okular/docdata It does not show again when you open the same PDF because either: a) Has a different name b) Has a different size Um, I'm not sure that's working then. This is what I do: 1) okular test.pdf 2) press F6 to enter review mode 3) select "inline note" 4) click somewhere on the document to start inserting the note 5) write "Test" and click OK [now the document has a note with the text "Test"] 6) choose File->Save As 7) enter test_annotated.pdf as the file name 8) quit okular 9) okular test_annotated.pdf And there are no annotations on the PDF just opened by okular. You added the annotations to test.pdf, as said "Save As" does nothing with annotations, so you need to open test.pdf and not test_annotated.pdf to get your annotations back Ah! So the annotations are saved always, regardless of any file->save* operations. I guess it just didn't occur to me to look at the original PDF, not the one I tried to save with annotations... Well, helpful to know that the annotations are still somewhere :P "and the documentation clearly states the behaviour." The problem is that people are unlikely to read the documentation for what seems to be totally standard PDF behavior. Do you expect people to read the documentation before using a tab bar on a web browser? Before trying to print something from a word processor? These are standard behaviors, and users would expect them to behave in a standard manner. Annotations are a standard part of pdfs. Users see the word "annotations" and they assume that these are the standard annotations used by many other pdf programs. Users simply aren't going to read the documentation before using what seems to be a standard behavior. And in this case they will likely waste hours of their time because of it. And it is not just that they are different, they serve radically different fundamental purposes. Annotations in other pdf programs are commonly used for transferring notes on the document from one person to another in a consistent and platform-independent manner. That is not possible with your version of annotations, which apparently are intended for making personal notes not intended to be shared with anyone else. The principle of least surprise comes into play here. What would be more surprising for a user: that their pdf program behaves in a manner similar to many other pdf programs, or that it randomly uses the exact same name for something not only totally different, but something that serves an entirely different and totally incompatible purpose? I think that if a program is going to radically violate user expectations, potentially losing them hours or even days of work in the process, it is not unreasonable to warn them beforehand in a visible manner. The documentation is simply not visible in this scenario, because as I mentioned users don't normally read the documentation for what they think is a standard behavior. There again here we are with "PDF viewer expectations" bla bla bla, does the standard PDF viewer open PS files? what about djvu files? ODT files maybe? Or even XPS? ePub? Stop repeating the same argument i read it once, i don't need to waste more time reading it again. Once again, how the program was designed and how users expect it to behave are two entirely differently things. The whole point of the principle of least surprise is that what matters is how users interpret the program, not how it was designed. The real question is "are users likely to read the documentation before using the annotation feature". If not, then the discussion in the documentation is not sufficient. When users open a pdf document in okular, they are using it as a pdf reader. Yes, okular can read other documents. But for the most part the interaction with those documents is consistent with how you interact with them in more specialized readers. For the most part standard pdf features behave like standard pdf features. But you have one feature that is labeled the same as a standard pdf feature, looks the same as a standard pdf feature, but behaves radically different. If okular overall did its own thing and didn't behave at all like standard pdf readers, then people would expect this one feature to also behave differently. But when pretty much everything behaves like a standard pdf reader, users wouldn't expect one random feature to behave radically differently. So yes, from a developer standpoint okular is not just a plain pdf reader. But when a user is looking for a way to annotate their pdfs in linux, they open it in okular, and they see an "annotate" feature, I think that is not likely to be at the front of their mind. I think they are likely to assume that it behaves in a pretty standard manner, just like pretty much everything else they have seen up to that point. Certainly everyone besides you who has commented here saw it that way. Man, which part of "stop repeating the same argument i read it once" did you not understand? I was trying to clarify what I said and to address your earlier response. (In reply to comment #20) > Man, which part of "stop repeating the same argument i read it once" did you > not understand? Man, try learning some manners! I'm not sure which planet you've been living on these past few years, but users don't read documentation when stuff seems straightforward. So your repeated "its documented" argument is invalid and barking up the wrong tree. And if you keep tossing that attitude the users' way, good luck in the software development world. You may make it as someone who designs and implements libraries. If you're lucky. Oh, and repeating "stop repeating your argument" is seriously unhelpful since you obviously don't understand it and aren't even trying to. If you don't want to implement this, fine, just keep going the way you have these past couple of years and ignore the comments. Stop antagonising! PS: I can understand that/why you're frustrated when users don't read docu or the whole thread (by which I mean the report this one split off from). But that's just life and taking it out on one of the few who are actually trying to isn't the way to go about this. Seriously, not replying and working on stuff that interests you is way more productive and will keep the discontent within limits. Bickering about it like an adolescent teen isn't going to help anyone. Just to add something productive to this thread: The way to fix this would obviously be to change the (misleading) "annotations" into something like "notes", or some hybrid between "okular" and "annotations" ("okutations"?) or "notes" ("okunotes", "oku-notes", whatever). A warning isn't really that useful. ********************** Oh, and repeating "stop repeating your argument" is seriously unhelpful since you obviously don't understand it and aren't even trying to. ********************** You are wrong, i totally understand your point of view, that is your point of view, it doesn't make it correct. The fact that you explain it four times like if i was an idiot that is not able to understand simple sentences speaks so much for your hability of empathizing. ********************** PS: I can understand that/why you're frustrated when users don't read docu or the whole thread (by which I mean the report this one split off from). But that's just life and taking it out on one of the few who are actually trying to isn't the way to go about this. Seriously, not replying and working on stuff that interests you is way more productive and will keep the discontent within limits. Bickering about it like an adolescent teen isn't going to help anyone. ********************** You know the same can be applied to your behaviour? The need to keep saying the same again and again seems to imply you "need to win", have the last word and this way i'll punish the developer for not doing *what is right*. So let's make it obvious, i see your point, and i was not against adding a warning, until you came here and started being a pain. Let me remember you that being a pain will not get you what you want in real life, unless you are an adolescent teen and all your parents want to do is keep you happy. You know, the one thing I hate more than users not reading the bugthreads is the developers not reading. You should really go back and check *who* said *what*. You're talking to multiple persons here, and not all of us have the same approach to the problem. Also, you may want to practice ignoring those that just add noise. Adding more will likely not shut them up. (Just to make that explicit: I don't particularly care for or about your squabble with Todd. Sami Liedes misunderstood something and apologised. I'm annoyed at having 10+ emails for this bug which add *no* value or progress. I'm even more annoyed at you for publicly behaving like an ass on this bugthread. You can just tell Todd once that you disagree and then take the matter off the thread if you absolutely have to continue arguing. No need to add to the noise.) I'd like for this thread to get back on track. That means discussing the warning and improving on my suggestion above, perhaps even adding and discussing alternatives. If you want to bicker, stick to private email! I was trying to be calm and stick solely to facts and logic, but I do find it dishearting that not only did you casually dismiss my posts as "bla bla bla", but you weren't even paying enough attention to notice that you were dealing with two different people or reading carefully enough to see that my three posts made different points and were on completely different subjects (the first was about principle of least surprise, the second was about whether documentation was sufficient, and the third was whether being more than a pdf reader was a good reason). In other words, the latter two posts were not repeating the same thing, they were addressing your responses to my earlier posts. @Todd: honestly, all your lengthy posts are just a more lengthy repetition of comment #1. The real points are there only, which I thank you for, and it's enough. @reini: Noone is disagreeing with anyone. The point here is that the key point of the bug have already been said in comment #0 (i.e. the initial description) and comment #1. Everything else, you think that or not, is just unuseful user addedum to a developer ticket. @Reini: I do read people names when reading comments. Prove i did not. (In reply to comment #27) > @reini: > Noone is disagreeing with anyone. The point here is that the key point of the > bug have already been said in comment #0 (i.e. the initial description) and > comment #1. Everything else, you think that or not, is just unuseful user > addedum to a developer ticket. According to comment #4 we still need to settle on the exact text of the warning, so that is something that should be discussed. Apart from that, you're basically regurgitating my point: I want the useless chatter to stop/move to a more private communication channel. (In reply to comment #28) > @Reini: I do read people names when reading comments. Prove i did not. In comment #24 your reply to me only makes sense if you think that I'm either Todd or Sami (or both). That, or you're just trolling on purpose. @29: Touché :D Ok, so here is my proposal for a (shorter) warning text (based on the proposal in comment #5): Warning: Annotations are for local use only! You will NOT be able to send them to any other person (via E-mail, Social Networks, USB flash drive, etc.) and they will NOT show up in printouts! I'm sure you could come up with something better, but it's still better to have that as a warning than nothing. I knew Okular doesn't save its annotations within the PDF file, but not every user is reading planet kde ;) *** Bug 295663 has been marked as a duplicate of this bug. *** Seems like annotation saving in PDFs is implemented for KDE 4.9: https://bugs.kde.org/show_bug.cgi?id=151614 So i guess this bug could be closed as soon as bug no 151614 is? This bug is about annotations in general, not just for PDF. Fabio, is this something we kind of do with your patches? (In reply to comment #35) > Fabio, is this something we kind of do with your patches? On non-PDF docs we say: "Your annotations are saved internally by Okular. You can export the annotated document using File -> Export As -> Document Archive". Which kind of suggests that they will be saved in a Okular-only format, but doesn't warn about the missing printing functionalities. Right, could you find a way to include that information in the dialog? So, is th(In reply to comment #33) > Seems like annotation saving in PDFs is implemented for KDE 4.9: > https://bugs.kde.org/show_bug.cgi?id=151614 > So i guess this bug could be closed as soon as bug no 151614 is? Bug https://bugs.kde.org/show_bug.cgi?id=151614 is closed, but this issue isn't even confirmed (I guess it's necessary to give it at least this status - the other question is whether it ought to be marked solved or invalid after the saving of annotations if implemented and released). I guess a lot of people have lost some thousand hours of work as the behavior is really counter-intuitive (a "<b>universal</b> document viewer" dealing with the "<b>portable</b> document format", I'd like to see the person thinking about checking the docs whether annotations are (statically) (ex)portable to the same set of appilcations the annotated pdf is). Nevertheless as reinventing the wheel seems to be a common sport for pdf viewer writer - and okular is still the best free tool -, a lot of people depend on okular due to it's unique annotation feature, or reach into their pockets or go back to windows - or whatever horrible scenario you can imagine. As of KDE Applications 17.12, automatic saving of annotations to the external location has been removed. For PDFs, you can save directly. For unsupported file formats, you get this warning upon saving or closing: "You are about to save changes, but the current file format does not support saving the following elements. Please use the Okular document archive format to preserve them." As Comment 1 is about "standard conformance", this probably concerns PDFs and has been achieved. Therefore I am closing this bug now. For files like JPGs, a warning will be shown although not upfront, but why would anyone expect saving annotations natively to work anyway? IMO the warning is good enough now. If anyone cares about a warning upfront and also an indication that printing annotations won't work (yet) in this case (which is more of a missing feature, actually), please open a new bug without the noise and clearly state your use case. |