the problematic PDF file.
https://github.com/seanlis/seanlis.github.io/raw/master/tmp/Database%20Systems%20A%20Practical%20Approach%20to%20Design%20Implementation%20and%20Management.pdf

I've got the same problem with this file: https://www.adobe.com/products/postscript/pdfs/PLRM.pdf

The problem might be related to that comment: https://bugs.kde.org/show_bug.cgi?id=151614#c168
<quote>
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.
</quote>

If it were the case, I have no way to know if the file does have embedded annotations, it wouldn't actually be a bug.

However this saving of annotations in external XML files is very, very convenient because it provides both persistent annotations and unmodified original file, and the fact that it's not possible for some files is a hindrance.

The status could be changed to confirmed and the importance to wishlist (if it's actually the non buggy behavior described above).

Should be solved by this issue: https://bugs.kde.org/show_bug.cgi?id=350991

(In reply to Steven Roose from comment #3)
> Should be solved by this issue: https://bugs.kde.org/show_bug.cgi?id=350991

It wouldn't to me, because the "annotations" which are not saved here (I mean bug 357536) are stored externally, which is a behavior more convenient in many cases because it does not modify the original document neither does it create copies of it...

Here is a workaround, from #ghostscript irc channel:

gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dShowAnnots=false -sOutputFile=stripped.pdf input.pdf

(refer to http://ghostscript.com/irclogs/ at date 2016-06-30 for caveat; as expressed it might modify the original file during the process of removing the annotations; and cleaner solution should be attained using "mutool run".)

FWIW we're disabling automatic annotation saving soon, see  https://phabricator.kde.org/D8642

Saving annotations to the file from Comment 1 with Okular from KDE Applications 17.12 Beta and Poppler 0.61 worked fine, i.e. just the same as for every other PDF. Note that Okular now behaves like a normal editor, i.e. no more autosave.

Same for https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.pdf.

Sean: I guess your issue was about being forced to use "Save As", which is fixed. If you actually want autosaving (e.g. every 5 minutes), please open a new wish for that.

Chris: Your issue from the first part of comment 3 is solved. Comment 4, i.e. being able to export annotations to a file, is a totally different issue, so please open a separate wish for it. Comment 5 concerns another topic again (removing annotations), which works just fine in Okular. This applies even to encrypted files (you might have to untick "Obey DRM limitations" in Okular's settings). Please open a new bug for any additional problems.

(In reply to Henrik Fehlauer from comment #7)
> Saving annotations to the file from Comment 1 with Okular from KDE
> Applications 17.12 Beta and Poppler 0.61 worked fine, i.e. just the same as
> for every other PDF. Note that Okular now behaves like a normal editor, i.e.
> no more autosave.
> 
> Same for
> https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.
> pdf.
> 
> Sean: I guess your issue was about being forced to use "Save As", which is
> fixed. If you actually want autosaving (e.g. every 5 minutes), please open a
> new wish for that.
> 
> Chris: Your issue from the first part of comment 3 is solved. Comment 4,
> i.e. being able to export annotations to a file, is a totally different
> issue, so please open a separate wish for it. Comment 5 concerns another
> topic again (removing annotations), which works just fine in Okular. This
> applies even to encrypted files (you might have to untick "Obey DRM
> limitations" in Okular's settings). Please open a new bug for any additional
> problems.

I was very fond of the specific behavior of Okular, consisting in saving annotations in a separate XML file: The original file was never modified, that is to say, not before the user was to perform some "export" action, and to my opinion, it was very very convenient.
So we have to say goodbye to this behavior a la Xournal, or a la Gimp.
I hope undo interface will be better that what there is today: today there are annotation actions which are very difficult to undo:
When one draw a thin line, or a rectangle, it is sometime difficult to put the pointing device with enough accuracy on the line in order to be able to delete it. Sometime, you can even have "invisible annotation", like a rectangle, so small, that it is not actually visible, made by mistake.
In Xournal, the selection mechanism is much more convenient: you can draw a rectangular selection, that select everything which is inside.
So my hope is that it will still be usable, and that we wont have to resort to git to be able to make the undo.

Otherwise I've duly noted that the behavior has changed and that the bug is fixed.
And that the change is to be expected from applications 17.12 and onward.

Keyboard shortcuts work just fine for undo (Ctrl + Z). You might also want to look into the "Reviews" sidebar, where all annotations are conveniently listed, no matter how small or invisible.

(In reply to Henrik Fehlauer from comment #9)
> Keyboard shortcuts work just fine for undo (Ctrl + Z). You might also want
> to look into the "Reviews" sidebar, where all annotations are conveniently
> listed, no matter how small or invisible.

I agree, you are perfectly right. My mistake, I forgot about this "Reviews" sidebar.