Version: (using KDE 4.1.3) OS: Linux Installed from: Ubuntu Packages The okular concept of "different files" doesn't seem to match that of the underlying filesystem. 1. Create file F1.pdf in directory A. 2. Open okular and perform a review item (e.g., highlight some text). 3. Copy file F1.pdf to directory B. 4. Open okular... the text is highlighted (even though it's physically a different file). 5. Copy the original file F1.pdf to F2.pdf (in directory B) 6. Open okular... the text is not highlighted. This seems very inconsistent, and is certainly confusing to the user. I would expect that step 3 would produce a CLEAN copy (i.e., with no highlighting associated). But the only way to have a clean document (I've experimented quite a bit with this) seems to be to give the document a different name in the second directory. This is an unacceptable restriction in many environments (for example, legal ones), where the names of documents are not allowed to be changed. Incidentally, even more confusing scenarios are easily possible; just to name one of many: 1. Create file F1.pdf in directory A. 2. Copy file F1.pdf to directory B. 3. Open okular and perform a review item (e.g., highlight some text) on the file in A. 4. Open okular and look at F1.pdf in B... it's now highlighted!
That's how it works by design. Given that reviews are not saved inside the file it's the only way you have not to lose the reviews when you move files.
Let me be sure I understand what you're saying. I apologize if I am misunderstanding. You are saying, I think, that the designed behaviour is that if I have five identical files on my system, all with the same name but in different directories, the user should be prohibited from should be prohibited from highlighting those documents differently. I'm sorry, but as a user that prohibition makes no sense at all to me. Here is the actual use case: I am reviewing several patents right now, and they all refer to different parts of document X; so I have several copies of document X, each associated with one patent; but okular will not let me highlight those different copies of X independently. How can this be a good thing? Do you want to take this discussion offline? It's not really appropriate for a bug report. ---- I just spent about an hour trying to understand okular's notion of a file, and frankly it has me completely stumped. Whatever notion okular has, it is not at all obvious to the user. Every time I think I understand it, I can come up with a case that breaks my understanding :-( Is there a document somewhere that clearly explains how reviewing is designed to work when applied to multiple files with the same contents and/or names?
(In reply to comment #2) > You are saying, I think, that the designed behaviour is that if I have five > identical files on my system, all with the same name but in different > directories, the user should be prohibited from should be prohibited from > highlighting those documents differently. Not at all. They can have the very same name, as long their size is different. They "key" used for metadata storage is build up with name AND file size. > I just spent about an hour trying to understand okular's notion of a file, and > frankly it has me completely stumped. Whatever notion okular has, it is not at > all obvious to the user. Every time I think I understand it, I can come up with > a case that breaks my understanding :-( ? what "notion of a file"?
Pino, he said "five identical files", so yes, the file size is the same too. As said, identical files with the same name are the same file to okular in the regard of reviews. This is a bug but also a feature (moving files around and not losing the reviews) In kde 4.2 we have a thing called "okular archive" that bundles the pdf and the reviews in a different file with .okular extension but given your problem with renaming files i think that won't help either.
It sounds like the "okular archive" might solve one problem (the one I have at the moment: that I want multiple identical files, with identical names, to be associated with different reviews), but as you suggest it sounds like it will have its own problems regarding what happens when one moves the underlying files. I don't think it's correct to call the current situation a "bug but also a feature". I think it's more like "the current implementation of a particular feature gives rise to a bug". I'm not saying that the feature that's implemented is unimportant -- not at all; I think it's pretty vital to okular being useful. However, the limitation imposed by the current implementation -- of not being able to associate different reviews with multiple identical files with identical names -- is a terrible restriction (especially since there's no warning anywhere about it). I can't see businesses being able to use okular with that restriction. Somehow, okular needs a way to distinguish /directory1/file.pdf from the identical /directory2/file.pdf so that different reviews can be associated with them. Maybe there's no automatic way this can be done (I can see that it's a difficult problem, but it's not obvious to me that there's no automatic solution), but at the very least a manual system could be used so that the user is asked whether the two files are supposed to share highlighting. I'm kind of thinking aloud here, for which Aaron chastised me recently, so I'll stop doing that. But at the end of the day I think there's definitely a problem here that needs to be addressed somehow. From a developer's perspective it may look like a "wish" rather than a "bug", although to me as a user it definitely has the appearance of a bug. Maybe the idea of an okular archive solves all, or at least the worst, problems. I guess I'll find out and revisit the issue when 4.2 is released for Kubuntu. Incidentally, mostly okular is simply fabulous.
I'm going to confirm this as a bug, but i don't think we'll have a solution for this unless we decide not to autosave annotations/forms anymore, which may actually be a good idea if we can find a way to properly make the user aware of the changes.
This won't be anymore the case starting with the Okular that will be part of KDE Applications 17.12 (aka okular 1.3.0)