[okular] [Bug 383651] New: Custom/image stamp annotations are not saved into the PDF file in a way that can be printed or that other readers can see

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

Bug ID: 383651
Summary: Custom/image stamp annotations are not saved into the
PDF file in a way that can be printed or that other
readers can see
Product: okular
Version: 1.0.0
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: okular-***@kde.org
Reporter: ***@zoho.com
Target Milestone: ---

Okular 1.0.3 on Kubuntu 17.04

A few years ago, Okular gained the ability to save annotations into PDF files:
https://bugs.kde.org/show_bug.cgi?id=151614

For the most part, it works great! There is one problem: custom/image stamp
annotations are not saved in a way that can be printed or that other PDF
readers can see. I tested many.


STEPS TO REPRODUCE:
1. Open a PDF file with Okular
2. Define a custom image stamp (Configure Okular > Annotations > Add > Stamp >
enter a valid path to an image in the combobox)
3. Stamp your image into the document
4. File > Save As > Save the document somewhere
5. Use Okular to print the document or open it document in a non-Okular PDF
viewer


EXPECTED RESULTS:
The image stamp is visible when the document is printed or viewed in a
non-Okular PDF viewer


ACTUAL RESULTS:
The image stamp annotation is not visible In any of the non-Okular PDF viewers
I had available: Adobe Acrobat, Foxit Reader, SumatraPDF, the PDF readers built
into Firefox and Microsoft Edge. Acrobat reader can see and manipulate the
*outlines* of the annotations, but the outlines have no images in them.


ADDITIONAL INFORMATION:
This affects a very common use case: wanting to add an image of the user's
signature to a PDF document to sign it and send it back to them. When they open
the file, the signature will not be visible unless they open it with Okular
(unlikely).

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #1 from Nate Graham <***@zoho.com> ---
Is this caused 100% by https://bugs.freedesktop.org/show_bug.cgi?id=23108? Or
are there other things that need to be done if/once poppler adds appearance
streams for rubber stamps?

[Anderson Medeiros Gomes]

https://bugs.kde.org/show_bug.cgi?id=383651

Anderson Medeiros Gomes <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[dharman]

https://bugs.kde.org/show_bug.cgi?id=383651

dharman <***@10100.to> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@10100.to

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@kde.org

--- Comment #2 from Nate Graham <***@zoho.com> ---
Albert, will the printing case be resolved with
https://bugs.freedesktop.org/show_bug.cgi?id=102513?

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #3 from Nate Graham <***@zoho.com> ---
(in combination with https://phabricator.kde.org/D7688, of course)

[Oliver Sander]

https://bugs.kde.org/show_bug.cgi?id=383651

Oliver Sander <***@tu-dresden.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@tu-dresden.de

--- Comment #4 from Oliver Sander <***@tu-dresden.de> ---
No. Your problem really smells like a problem with annotation handling, and
printing is just a symptom of something deeper.

You may be able to partially circumvent your printing problem now that we have

https://git.reviewboard.kde.org/r/130218/

With this patch, if you select rasterized printing, then Okular will render
(almost) right into a QPrinter object, rather than converting the file to
postscript and rendering that. I'm fairly confident that this will make your
stamps appear on the printout.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #5 from Nate Graham <***@zoho.com> ---
*** Bug 377567 has been marked as a duplicate of this bug. ***

[Simon Andric]

https://bugs.kde.org/show_bug.cgi?id=383651

Simon Andric <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |usability

[Tobias Deiminger]

https://bugs.kde.org/show_bug.cgi?id=383651

Tobias Deiminger <***@posteo.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@posteo.de

--- Comment #6 from Tobias Deiminger <***@posteo.de> ---
Just had a look into it, this is what I found. Dependent on users choice,
Okular sets the annotation dicts /Name entry to standard names ("Approved",
"Confidential", ... see PDF 32000-1:2008, chapter 12.5.6.12 Rubber Stamp
Annotations, Table 181), but also to non standard names ("okular", "kde",
<path_to_your_custom_image>). Conforming readers implement a representation for
the standard names (may look a bit different as in Okular, but at least
something reasonable is shown). But of course non standard names like "okular",
"kde", <some_local_path> are not understood by other readers. A portable way to
have such custom stamps would be to add an /AP entry with the full icon
representation into the PDF. Unfortunately, Poppler can't generate appearance
streams for stamps yet. Note that Poppler #23108 is a bit different, it is
about hardcoded default appearance streams, not about generating ones for your
custom image.

There's another special thing about stamps. Contrary to most other annotation
types, stamps are not rendered by Poppler, but by Okular itself. Okular first
looks for /Name in ui/data/stamps.svg (contains "approved", "confidential",
"departmental"...). If there's no match, it uses KIconLoader lookup an icon.
Not rendering with Poppler probably introduces special handling when printing,
haven't checked that yet.

I guess an ideal solution for this bug will require aid from Poppler side
(maybe a new API to store raster and vector graphics as appearance stream into
the PDF, and some predefined appearance streams for the standard names so that
stamps without /AP can be rendered).

[Oliver Sander]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #7 from Oliver Sander <***@tu-dresden.de> ---
Should we split this into a set of separate smaller issues, then? E.g., issues
with stamps with standard appearances seem to be quite independent from custom
stamps.

[Tobias Deiminger]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #8 from Tobias Deiminger <***@posteo.de> ---
How about this breakdown? Boils down to the same root causes a bit...

Okular #1: Stamp Annotations are not printable
(I can confirm this, for both standard and non-standard icon names)
Root cause: PDF print requests are forwarded from Okular to the Poppler
generator (see PDFGenerator::print). But Poppler can't render stamps for two
reasons:
-Poppler doesn't implement default appearance streams for standard icon names,
so it can't render stamps like "Draft" and "Approved". See [1], "I leave the
bug open becuase there are still annotations missing default appearance streams
(Free Text annots, rubber stamp, ...)".
-Poppler can't generate/render/save an appearance streams for your custom
*.svg, *.png, whatever image yet. Displaying them in Okular on screen only
works because Okular renders stamps on its own.

Okular #2: Custom stamp annotations (i.e. non standard icon name) are not
visible in other readers
Root cause: If stamp is created by Okular+Poppler, no appearance stream is
generated/embedded into the PDF. Other readers should implement a default
appearance stream for standard icon names, but for non-standard icon names like
"kde", "okular", <path_to_local_file> they can't know what to display. Maybe of
interest is this pdf.js (firefox) issue [2]: "Most annotations, even
unsupported ones, render just fine in PDF.js because of their appearance
stream. However, there exist PDF files with annotations that do not have an
appearance stream (even though this is a deprecated practice). In the latter
case, PDF.js displays nothing.". There have been some thoughts about handling
of appearance streams in Poppler [3], but I don't know the current state and
desire there.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=23108#c21
[2] https://github.com/mozilla/pdf.js/issues/6810
[3] https://lists.freedesktop.org/archives/poppler/2009-June/004789.html

[Oliver Sander]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #9 from Oliver Sander <***@tu-dresden.de> ---
Is it too late to turn this into yet another gsoc project?

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #10 from Albert Astals Cid <***@kde.org> ---
(In reply to Oliver Sander from comment #9)

Post by Oliver Sander
Is it too late to turn this into yet another gsoc project?

No, the student application deadline is March 27
https://developers.google.com/open-source/gsoc/timeline

[Oliver Sander]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #11 from Oliver Sander <***@tu-dresden.de> ---
Can somebody please post this on the gsoc project list for me? Thanks!

Project: Improve custom stamp annotation handling

Brief explanation: Okular does display stamp annotations, but the support
is somewhat incomplete. This particularly shows when trying to use stamp
annotations with a custom image. For example, such annotations can be
added in Okular, but they cannot be saved to the pdf file in a way
that any other pdf viewer can read. Also, they will not appear on print-outs.

The underlying reason for this is that Okular renders these stamps itself,
rather than relying on the poppler library, which does all other pdf
rendering. Goal of this project is therefore to teach poppler how to
render stamp annotations, and then make Okular use that new functionality.
More details can be found in the bug report [0].

[0] https://bugs.kde.org/show_bug.cgi?id=383651

Expected results: Poppler should render stamp annotations. Annotations
should be printable from Okular. Custom stamps inserted via the Okular GUI
should be visible in other pdf readers.

Knowledge prerequisite: C++, and a bit about the pdf format.

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #12 from Albert Astals Cid <***@kde.org> ---
You should really add it to the wiki for yourself, *personally* i've like 100
unread emails, half of which are people waiting for me to review their code, so
I really don't have time to add it myself.

[Oliver Sander]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #13 from Oliver Sander <***@tu-dresden.de> ---
Albert, you are not the only busy person on this planet. Last time I tried I
couldn't log in to the wiki page. Now it works all of a sudden. What do I
know...

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #14 from Nate Graham <***@kde.org> ---
Thanks for adding it to the Wiki, Oliver!

https://community.kde.org/GSoC/2018/Ideas#Project:_Improve_custom_stamp_annotation_handling

[Simone Gaiarin]

https://bugs.kde.org/show_bug.cgi?id=383651

Simone Gaiarin <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=354894

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |burton+***@inputne
| |uron.io

--- Comment #15 from Nate Graham <***@kde.org> ---
*** Bug 394620 has been marked as a duplicate of this bug. ***

[Kevin Burton]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #16 from Kevin Burton <burton+***@inputneuron.io> ---
This bug is related to the issue of default annotation appearance handling.

It isn't just "image stamp" handling.

There are two bugs here.


https://bugs.freedesktop.org/show_bug.cgi?id=23108

https://bugs.freedesktop.org/show_bug.cgi?id=106635


My bug was here but marked as a duplicate of this bug.

https://bugs.kde.org/show_bug.cgi?id=394620

I'd like to propose that we create a tracking bug or merge this with a larger
bug regarding annotation appearance.

What I'm worried about is that if it goes to GSoC or someone else handles it
they won't resolve the larger issue of highlight annotations, note annotations,
etc. All these are VERY important to resolve now.

Right now Okular generates PDFs that aren't usable by other clients and this is
dangerous.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #17 from Nate Graham <***@kde.org> ---
I agree that this is important and fixing it should be a high priority.

We have a number of other bugs relating to this subject:
- https://bugs.kde.org/show_bug.cgi?id=275371
- https://bugs.kde.org/show_bug.cgi?id=378186
- https://bugs.kde.org/show_bug.cgi?id=390293

Are any of those more appropriate?

There's no real benefit to having a master "annotations don't work in other PDF
readers" bug. Better to track the individual issues with individual bugs, IMHO.

[Kevin Burton]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #18 from Kevin Burton <burton+***@inputneuron.io> ---
Thanks Nate.

I think one main concern I have is for other users of Okular using annotations.

Some of these bugs are rather old and I suspect the issue of highlights and
notes not being visible impacts Okular from years ago.

If we can't fix these in the next release, I'd like to propose that the
annotation functionality be disabled.

The reason is that if a user installs Okular, then migrates away from Okular
(say they go from Ubuntu to MacOS/Windows) then they lose all their annotations
essentially.

This is a data loss issue.

If the user can't see on the page where his annotations were, in other PDF
readers, they're essentially gone.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #19 from Nate Graham <***@kde.org> ---
That has been discussed before and rejected, since that would represent a loss
of functionality--a great deal of which *does* work in other viewers, and all
of which works in Okular itself.

Let's focus on fixing the bugs rather than getting into the weeds with a
bruising argument about whether the feature is ready for prime time yet. It's
clearly not, but turning it off until it is isn't an option.

Are you a programmer? Are you able to review any of the poppler patches
floating around?

[Kevin Burton]

This post might be inappropriate. Click to display it.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #21 from Nate Graham <***@kde.org> ---
I know, and I don't necessarily disagree with you. But as a fellow programmer
someone who's watched this project for a while and advocated for the same
things, let me tell you that disabling the feature or showing a warning is not
going to be accepted. It is what it is, sorry.

Let's focus on fixing the bugs. Where do you think we should start?

[Kevin Burton]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #22 from Kevin Burton <burton+***@inputneuron.io> ---
Do you have a thought on the poppler default annotation appearance issue?

That's probably the greatest bang for the buck. If that fixes 80% of the
problems then we should focus a patch there.

I've asked for commentary on their bugs.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #23 from Nate Graham <***@kde.org> ---
I agree that we should focus on Poppler. If I'm reading
https://bugs.freedesktop.org/show_bug.cgi?id=23108#c21 correctly, patches were
merged that handled some annotation types, but not all of them. We should
probably focus on the remaining annotation types that still need default
Poppler appearance streams.

[Kevin Burton]

https://bugs.kde.org/show_bug.cgi?id=383651

--- Comment #24 from Kevin Burton <burton+***@inputneuron.io> ---
I'll probably have to look and see if we can confirm that this is the problem.

maybe a test app that generates all the annotation types ...

I'm working on a separate project that can export the annotations as JSON from
PDF.js and make them machine readable.

I might be able to include the colors there so that we could have a unit test
or some way to verify that they work.

poppler might already have some options for this.

[Manuel López-Ibáñez]

https://bugs.kde.org/show_bug.cgi?id=383651

Manuel López-Ibáñez <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com