(1) "Handling" of PDF Form Data after signing / (2) PDF/A question

[michaelof]

(1) Not a bug, maybe also not a feature request, NOT sure if this out of scope for PDF-Over, but let me give it a try to ask:

After a long time working without an issue, I'm now getting some unusable behavior on my latest Linux version (OpenSUSE Leap 15.6, Okular (PDF Reader) 23.08.5. I've described it in detail here. In German, please advice if I should translate in English.

As of now, as the "doc has changed" msg only happens in Okular and e.g. NOT in Adobe Acrobat Reader under MSWIN, IMHO this is an Okular-specific bug.

But I have a general question towards PDF-Over:

If I have (and I very frequently have, est. 75+% of all my to be signed PDFs) a PDF with form data to be entered before signed: Wouldn't it make sense (if possible) to treat the entered form data as to be unchangeable after signing, include them permanently, as all other pieces of information into the signed PDF?

(2) As also described here, PDF is shown as "unchanged" within Adobe Acrobat Reader in Win11, but with "corrupted" form data. Some errors are shown like "embedded font are not available" or similar. Which confuses me, as I understood PDF/A a an idea to embed EVERYTHING needed for long time access??

FYI opening the signed PDF on Android, with any PDF Reader I have (MuPDF, LibreOffice on Android,..., all from the (FOSS) F-Droid repository) shows the PDF completely fine. But these readersdon't check any signature information :)

[iaik-jheher]

The particular issue isn't familiar from Okular, but sounds like an issue we've had with MacOS's default PDF viewer, which also likes to make signature-incompatible metadata changes to any form PDF as soon as it is opened. As you state, that's a PDF viewer issue; they shouldn't be touching the signed document contents if you aren't changing anything. (Ideally, if you do change anything, they should also warn you before saving, but that's a different cup of tea.)

I'll look into your workaround, but can't make any promises. One thing you could try is printing the filled-out document as a PDF (not saving, but using a print-to-pdf print driver). That should render the form fields as immutable parts of the document.

---

PDF-Over will (should?) maintain the document's PDF/A compliance as long as the document was PDF/A compliant before you signed it. If you are sure that your document was PDF/A compliant before signing, and is broken afterwards -- can you provide a sample document? I'd be happy to take a look.

[michaelof]

(1) YOUR workaround, "print as pdf" before signing , is a perfect workaround for me: Easy for me, no work for you :)

(2) Looked into the pdf on Win11 again: Adobe Acrobat reader is a rolling release now, and the mentioned pdf looks today different on Win11 than it looks when signed and sent to Win11 last week: No "garbage" anymore, but still unusable, you have to click into each form field to get the form data visible, and the content disappears when clicking into the next form field. No "Embedded font missing" msg anymore.

But you mentioned "... PDF/A compliant BEFORE signing...": No need to dig into this anymore, you clarified my misunderstanding: I assumed that PDF-Over's "PDF/A" option set means that PDF-Over creates a PDF/A compliant (signed) PDF independent of source pdf's status. As this was a wrong assumption by me, subsequent "embedded font missing" NOW get's reasonable for me after your clarification, seems that pdf source was NOT PDF/A compliant.

THANKS !!!

[michaelof]

P.S.: As written in OpenSuse Forum, I've tested the "changed after signature" with the relevant pdf and with a pdf without forms, "Beitragssatzung". After your recent answer, I've tested with a pdf of an for sure different source: Sent Github's email about your today's post here to CUPS-PDF virtual printer, and signed the resulting pdf: NO ISSUE when opening with Okular!

So seems some mystic issue with the Sportverein's pdfs. Funny :D

[iaik-jheher]

I'd suspect it's an issue with (certain kinds of) form-field PDFs. Maybe ones with validation/auto-fill rules that are evaluated automatically? (Pure speculation on my part.) I'd still consider reporting the issue to Okular.

[michaelof]

It's me again, @iaik-jheher :)

As you recommended, I've opened an Okular bug report, could you please take a look at the latest comment here

Not sure, what Sune exactly means with "pdf spec" - does this refer to a general spec (like a RFC) how signatures should be padded/filled, or did you set this for PDF-Over-signed PDFs?