Bug 383651 - Custom/image stamp annotations are not saved into the PDF file in a way that can be printed or that other readers can see
Summary: Custom/image stamp annotations are not saved into the PDF file in a way that ...
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.0.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords: usability
: 377567 394620 416252 435904 447086 451541 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-17 23:00 UTC by Nate Graham
Modified: 2022-07-23 11:00 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2017-08-17 23:00:01 UTC
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).
Comment 1 Nate Graham 2017-08-17 23:31:40 UTC
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?
Comment 2 Nate Graham 2017-09-04 22:21:35 UTC
Albert, will the printing case be resolved with https://bugs.freedesktop.org/show_bug.cgi?id=102513?
Comment 3 Nate Graham 2017-09-04 22:22:28 UTC
(in combination with https://phabricator.kde.org/D7688, of course)
Comment 4 Oliver Sander 2017-09-05 07:10:38 UTC
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.
Comment 5 Nate Graham 2017-09-13 04:51:04 UTC
*** Bug 377567 has been marked as a duplicate of this bug. ***
Comment 6 Tobias Deiminger 2018-02-05 07:52:09 UTC
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).
Comment 7 Oliver Sander 2018-02-05 08:51:12 UTC
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.
Comment 8 Tobias Deiminger 2018-02-06 08:26:37 UTC
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
Comment 9 Oliver Sander 2018-02-06 08:46:30 UTC
Is it too late to turn this into yet another gsoc project?
Comment 10 Albert Astals Cid 2018-02-06 18:36:51 UTC
(In reply to Oliver Sander from comment #9)
> 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
Comment 11 Oliver Sander 2018-02-16 08:53:43 UTC
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.
Comment 12 Albert Astals Cid 2018-02-18 18:47:39 UTC
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.
Comment 13 Oliver Sander 2018-02-18 19:37:48 UTC
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...
Comment 14 Nate Graham 2018-02-19 22:13:21 UTC
Thanks for adding it to the Wiki, Oliver!

https://community.kde.org/GSoC/2018/Ideas#Project:_Improve_custom_stamp_annotation_handling
Comment 15 Nate Graham 2018-05-23 16:46:52 UTC
*** Bug 394620 has been marked as a duplicate of this bug. ***
Comment 16 Kevin Burton 2018-05-23 17:15:28 UTC
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.
Comment 17 Nate Graham 2018-05-23 17:21:36 UTC
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.
Comment 18 Kevin Burton 2018-05-23 17:27:02 UTC
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.
Comment 19 Nate Graham 2018-05-23 17:35:29 UTC
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?
Comment 20 Kevin Burton 2018-05-23 17:39:22 UTC
I am a programmer.  I'm able to review them and will get to them. I'm curious if this is the best solution. If it means just revising the poppler patches and that's the best path for 80% of the functionality then I'm good to go.

Also, another solution might just be a warning to the user the the annotations MAY not be viewable in all PDF editors and that we don't control those.  Then show them the warning once. 

My concern is that some of these bugs seem like they won't be readily resolved but a warning might be the best approach here. 

Data loss can really hit you
Comment 21 Nate Graham 2018-05-23 17:43:43 UTC
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?
Comment 22 Kevin Burton 2018-05-23 17:45:11 UTC
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.
Comment 23 Nate Graham 2018-05-23 19:09:13 UTC
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.
Comment 24 Kevin Burton 2018-05-23 19:50:52 UTC
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.
Comment 25 Dimitrios T Tanis 2019-02-20 21:28:52 UTC
Is there any update on this? 
I agree with Kevin that data loss can be a buzz but when advocating for the bells and whistles of linux and KDE as a pro business environment, sending an annotated  pdf that others can't view is even worst (I've just been hit by that).

It's been quite a few years since I've coded in C++ and Qt so I can't be of use in coding but I can help with testing if needed.
Comment 26 Valentin Melot 2019-04-22 16:26:20 UTC
Hello, is there some news about this bug? It is still happening in version 1.6.3. Thanks in advance!
Comment 27 Tobias Deiminger 2019-04-23 15:19:18 UTC
(In reply to Valentin Melot from comment #26)
> Hello, is there some news about this bug? It is still happening in version
> 1.6.3. Thanks in advance!
Afaikt there's no news, sorry.

@Nate, Kevin: You seem to focus on default appearances. I don't think they would fix this bug, can you explain how?

For my understanding we need to extend poppler so that it can generate and save appearance streams into the PDF file in a consistent way:
- either generate PDF operations from user image to draw image as paths
- or rasterize / convert user image to a sampled PDF image
- create AP structure, enter the generated image stream, enter additional resources
- update all resource references throughout the document
- save new and dirty objects

That all has not much to do with default appearances. Even if poppler had hard coded default appearances for stamps, non-Okular readers would not benefit from them unless the appearance is saved into the file, which is currently not possible and which is the toughest part to implement. And, "default" is quite the opposite to "custom" (as in the bug title).
Comment 28 Simone Gaiarin 2019-07-25 18:09:33 UTC
Git commit f15e8568a5330b6795b1dd5287a6a1530dc60476 by Simone Gaiarin.
Committed on 25/07/2019 at 18:09.
Pushed by gaiarin into branch 'master'.

General improvements to stamp annotation

Summary:
Configuration:
- Add push button to select custom stamp image
- Check if loaded image is usable as stamp or throw error
- Keep image proportions in previewer
- Move previewer below the combobox to display larger preview

Annotation tool:
- Keep stamp image proportion in annotation preview (while left mouse button is down)
- Adding the annotation with one-click (without holding the left mouse button and dragging) adds the stamp with original proportions
Related: bug 370381, bug 383652
FIXED-IN: 1.9.0

Closes T8074

TODO:
- [ ] Check if filters in file chooser make sense / propose better alternative
- [x] Update doc ( @yurchor will do it after we merge this)

Test Plan:
>From stamp annotation configuration dialog:
- Show a warning regarding limitations of the feature's current implementation
- Click push button next to combo box opens a file selector
- Selecting a corrupted image file should throw an error
- Selecting a good image file shows the preview of the image
- Select a horizontal image shows a large clear preview
- Select a vertical image file shows a smaller preview without messing up the visual of the config dialog
- Input a valid icon name in the combobox and the preview of the icon is shown

>From page view, select the stamp annotation with horizontal image file (not squared):
- Click and hold. The preview maintains proportions
- Single click. The stamp image in the pdf maintains proportions and has the same size of the click and hold preview.
- Add an annotation of the Okular custom stamps (internal SVG so treated slightly differently) do not create problems

Reviewers: #okular, ngraham

Reviewed By: ngraham

Subscribers: pino, aacid, yurchor, ngraham, okular-devel

Tags: #okular

Maniphest Tasks: T8074

Differential Revision: https://phabricator.kde.org/D22064

M  +62   -9    ui/annotationwidgets.cpp
M  +7    -1    ui/annotationwidgets.h
M  +25   -9    ui/guiutils.cpp
M  +8    -1    ui/guiutils.h
M  +1    -1    ui/pagepainter.cpp
M  +4    -4    ui/pageviewannotator.cpp

https://invent.kde.org/kde/okular/commit/f15e8568a5330b6795b1dd5287a6a1530dc60476
Comment 29 Nate Graham 2020-01-14 23:14:14 UTC
*** Bug 416252 has been marked as a duplicate of this bug. ***
Comment 30 Albert Astals Cid 2021-04-19 21:38:38 UTC
*** Bug 435904 has been marked as a duplicate of this bug. ***
Comment 31 Nate Graham 2021-12-16 19:22:05 UTC
*** Bug 447086 has been marked as a duplicate of this bug. ***
Comment 32 Jens 2022-03-10 17:57:37 UTC
I just came across this bug because I wondered why my signature (as a custom stamp) was not printed.
I don't actually need custom stamps to be saved in the PDF in a portable way, but they need to be PRINTABLE. Currently, when printing a PDF document (even into another PDF), the custom stamps are missing. Other annotations and marks are kept.

Is this a completely different issue or is this an aspect of this bug?
Comment 33 Oliver Sander 2022-03-11 11:00:56 UTC
If all you need is printing, then enabling 'force rasterization' in the print dialog will probably circumvent the problem for you.
Comment 34 Albert Astals Cid 2022-03-11 19:26:01 UTC
This has been fixed since Okular 21.12.0 assuming you run a moderately modern poppler, if you don't (e.g Neon users, you should either convince the Neon developers to stop using such an old poppler or find a new distribution to use).
Comment 35 Jens 2022-03-11 21:49:09 UTC
Thanks for the update.
What is the minimum poppler version that we need?
Comment 36 Albert Astals Cid 2022-03-12 00:08:03 UTC
Poppler >= 21.10
Comment 37 Albert Astals Cid 2022-03-15 21:35:54 UTC
*** Bug 451541 has been marked as a duplicate of this bug. ***
Comment 38 davidblunkett 2022-03-15 21:55:29 UTC
"If all you need is printing, then enabling 'force rasterization' in the print dialog will probably circumvent the problem for you."

Not working for me (21.08.1, poppler 21.06)
Comment 39 Nate Graham 2022-03-17 03:30:15 UTC
@David Albert said it was fixed in 21.12 (with the appropriate Poppler version) . You have 21.08.

@Albert Does this mean that Bug 275371, Bug 378186, and Bug 390293 should also be fixed?
Comment 40 dharman 2022-03-17 08:24:17 UTC
(In reply to Albert Astals Cid from comment #34)
> This has been fixed since Okular 21.12.0 assuming you run a moderately
> modern poppler, if you don't (e.g Neon users, you should either convince the
> Neon developers to stop using such an old poppler or find a new distribution
> to use).

Here, with a bare Kubuntu 21.10 installetd I've poppler 21.06.1. I think it isn't a Neon problem. Simply poppler need at newer version.
Comment 41 Albert Astals Cid 2022-03-17 09:04:50 UTC
(In reply to dharman from comment #40)
> I think it isn't a Neon problem. Simply poppler need at newer version.

Neon doesn't want (or can't)  provide a new poppler version, so it's a Neon problem.
Comment 42 Albert Astals Cid 2022-03-17 13:21:49 UTC
(In reply to Nate Graham from comment #39)
> @Albert Does this mean that Bug 275371, Bug 378186, and Bug 390293 should
> also be fixed?

Both 378186 and 390293 are unrelated to this as far as i can see.
Comment 43 davidblunkett 2022-03-22 22:42:54 UTC
Any chance getting this ported to 21.10 / Impish? because it's not showing for me (poppler 21.06.1-1) and it would be very handy...
Comment 44 Albert Astals Cid 2022-03-22 22:45:40 UTC
(In reply to davidblunkett from comment #43)
> Any chance getting this ported to 21.10 / Impish? because it's not showing
> for me (poppler 21.06.1-1) and it would be very handy...

You're asking to the wrong people.
Comment 45 davidblunkett 2022-03-22 23:03:08 UTC
Quite right - my mistake!