problems with signature fields
Hans, I have the following sample: \setupinteraction[state=start] \starttext \startTEXpage[offset=1em] \definefield[x][signature] \field[x] \stopTEXpage \stoptext I can only use Acrobat to sign PDF documents with signature fields generated by ConTeXt. Other tools sign the PDF document not producing a valid signature (Acrobat cannot read or validate it). From the source, signature has two objects (copied from the sample above): 2 0 obj << /DA (/rmtf 11.9552 Tf 1.1955 Ts 0 0 0 rg 0 0 0 RG) /DV <FEFF> /F 4 /FT /Sig /Ff 0 /Kids 1 0 R /MaxLen 1024 /Q 0 /Subtype /Widget /T <FEFF0078> /V <FEFF>
endobj
4 0 obj << /Type /Annot /DA (/rmtf 11.9552 Tf 1.1955 Ts 0 0 0 rg 0 0 0 RG) /F 4 /Parent 2 0 R /Q 0 /Subtype /Widget /Rect [ 14.033054 14.033054 70.40415 25.08072 ]
endobj
One of the tools that has issues with two objects for the signature field is the latest version (1.18) from mupdf-gl. mupdf-gl adds the signature value to the child (object 4) and not to its parent (object 2). I’m afraid this is also the same issue that AutoFirma (a e-signing tool developed by the Spanish government [https://firmaelectronica.gob.es/Home/Descargas.html]) has with these signature fields. When both objects are merged in one (as Acrobat Reader does when saving a copy), both tools generate documents contaning signatures totally unproblematic to be read validated by Acrobat. I suggested merging both objects back in 2017. You told me that simplifyng this would introduce too much complexity in ConTeXt only to save some bytes. Back then, I thought it was an minor improvement. Now I realized that this two objects for signature fiels are only valid for Acrobat. I wonder whether this improvement might be also easier to make in LMTX. Would it be possible that signature fields may have only one object, so that mupdf-gl and other tools have no problem signing fields PDF documents generated by ConTeXt? Many thanks for your help, Pablo -- http://www.ousia.tk
On 11/11/2020 9:46 PM, Pablo Rodriguez wrote:
Hans,
Back then, I thought it was an minor improvement. Now I realized that this two objects for signature fiels are only valid for Acrobat.
te hother tools hould be fixed ... indirect objects are pretty valid
I wonder whether this improvement might be also easier to make in LMTX.
not without changing the implementation of fields (which makes no sense ... in fact one can start to wonder about widgets of any kind now that flash is dropped which is needed/used for rendering of some image types in pdf)
Would it be possible that signature fields may have only one object, so that mupdf-gl and other tools have no problem signing fields PDF documents generated by ConTeXt? all is possible but i'm not sure if i want to uglify the implementation for the sake of buggy viewers
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 11/12/20 12:24 AM, Hans Hagen wrote:
On 11/11/2020 9:46 PM, Pablo Rodriguez wrote:
Hans,
Back then, I thought it was an minor improvement. Now I realized that this two objects for signature fiels are only valid for Acrobat.
the other tools should be fixed ... indirect objects are pretty valid
Many thanks for your reply, Hans. I totally agree, these tools need to be fixed. I reported the issue to one of the projects more than two years ago. I’m still waiting for a message about the issue report.
Would it be possible that signature fields may have only one object, so that mupdf-gl and other tools have no problem signing fields PDF documents generated by ConTeXt? all is possible but i'm not sure if i want to uglify the implementation for the sake of buggy viewers
In Windows (and I guess in macOS), saving a copy with Acrobat Reader DC seems to unify both objects. But I’m afraid Acrobat for Linux is too old for that (9.5.5). Many thanks for your help, Pablo -- http://www.ousia.tk
participants (2)
-
Hans Hagen
-
Pablo Rodriguez