Sporadically, the skribble signatures were only visible in Browser, but not recognized and thus not displayed in Acrobat (which is standard tool in my environment).
We saw that this is the case as soon as user have Unicode chars above ansi, like a list with square bullets, filled in one of the text fields (displayed correctly as well in browser as in Acrobat).
Here my trials to find out what is wrong:
According to https://www.pdf-online.com/osa/validate.aspx, used by skribble IT team, the empty pdf form conforms the standard (1.4 resp. 1.6.).
The filled form does not (this is the error message the skribble team sent to me):
"Validate conformance: PDF 1.4
(Test-1orig.pdf, E, Validation, Test-1orig.pdf, "The encoding for character code 9 in font 'ArialMT' is missing.", Font, appearance of widget of text field on page 2 in object 194
, Validation)
Document does not conform to PDF 1.4."
-> Arial 9pt is used in one of my text fields.
Tests showed that even simply saving the pdf in Acrobat leads to non-conformity from point of view of this tool, as Acrobat does something when opening the PDF.
In Acrobat Preflight, even the empty form shows a Page description error as soon as there is some text field in the document.
Analyzing the empty form with poppler shows: Arial (or another font, I tested with dejavusans) once embedded including unicode, once not embedded.
Code: Select all
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
BAAAAA+ArialMT TrueType WinAnsi yes yes yes 11 0
ArialMT TrueType WinAnsi no no no 13 0
Correcting the embedding
- via ghostscript: resulted in an empty Acroform, no matter what options were used to preserve the form.
- via Acrobat Preflight: when filling via IText as decribed above, text fields are unable to display chars above ansi and also tabs like char9 mentioned in the error message. It seems that the font information for the form fields is lost by the correction/form fields do not find the embedded fonts (while text field properties look correct in Acrobat when going in form tools).
I implemented a workaround by first bringing the form to standard using Acrobat Preflight and then explicitely setting the text fields to Arial including Unicode encoding, which works as desired.
In the end:
I am far away from understanding what the intitial problem with the "page description" is, which is identified by Acrobat and not identified by pdftools.
Also, I would like to know if there is any possibility to export the pdf form from OO in a way which does not need any postprocessing: perhaps I missed some property I could change.
So many thanks in advance to any who can help me.