PDF forms not creating proper children

Leonard Janis Robert König

23 Apr 2021 23 Apr '21

1:50 p.m.

Hello, I currently try to build a document with AcroForms, e.g., the examples from [1] also linked in the Wiki. The most recent example is in the form/ subdirectory and dated mid 2020. However, when building the file(s) with my ConTeXt distribution the file created is broken, in comparison to the PDF checked in into the Git. The more obvious difference is that the PDF in the repository can be filled in the Firefox 89 beta, while the other PDF doesn't even display the fields as forms. Running pdfinfo also yields:

...

Syntax Error: Form field child is not a dictionary

I suspect that due to some breakage the forms children aren't set in the AcroForms dictionary anymore? My ConTeXt versions are: # ArchLinux Repos context --version mtx-context | ConTeXt Process Management 1.04 mtx-context | mtx-context | main context file: /usr/share/texmf- dist/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2021.03.05 19:11 mtx-context | main context file: /usr/share/texmf- dist/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2021.03.05 19:11 # Debian Buster Repos mtx-context | ConTeXt Process Management 1.02 mtx-context | mtx-context | main context file: /usr/share/texmf/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2018.04.04 00:51 # Docker Image: Current mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.01.30 14:13 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.01.30 14:13 # Docker Image: Beta mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.01.30 14:13 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.01.30 14:13 # Docker Image: LMTX mtx-context | ConTeXt Process Management 1.04 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2021.04.14 22:58 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2021.04.14 22:58 # Docker Image: Beta from 2019-09 mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2019.09.10 20:03 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2019.09.10 20:03 The ConTeXt version of the checked in file on GitHub is (according to pdfinfo):

...

Creator: LuaTeX 1.10 7138 + ConTeXt MkIV 2019.08.20 17:20 Producer: macOS Version 10.14.6 (Build 18G5033) Quartz PDFContext

I also remebered another time were I toyed around with it and indeed that PDF also had broken form field children:

...

Creator: LuaTeX 1.12 7306 + ConTeXt MkIV 2020.03.10 14:44 Producer: LuaTeX-1.12

A broken version that I built locally using the :current IslandOfTeX [2] can be found at [3]. The version difference between the broken and not-broken PDFs hints that the breakage occured between 2019.08.20 and 2019.09.10-beta, while the Debian breackage might be due to a backport(?) Alternatively, this could just be a mistake on my side? Cheers Leo König [1]: https://github.com/fiee/ConTeXt [2]: https://gitlab.com/islandoftex/images/context/ [3]: https://mega.nz/file/ThcghTqb#JqRCSsd59bBbMgTMr3ahaPdU4LPlZd0cpA3ZFBJLJ3A

Show replies by date

Adam Reviczky

1 May 1 May

4:20 p.m.

Hi, I cannot get the signature working either, but almost certain it did work in February this year, as I have done some with MKIV.

...

From the test suite:

fields-007.tex \nopdfcompression \setupinteraction[state=start] \starttext \definefield[x][signature] \field[x] \stoptext Using the https://live.contextgarden.net/ with (LuaTeX 2.06 20200630 + ConTeXt MkIV 2020.06.30 17:30) looks good, but evince does not display the field. Adam On Fri, Apr 23, 2021 at 8:52 PM Leonard Janis Robert König wrote:

...

Hello,

I currently try to build a document with AcroForms, e.g., the examples from [1] also linked in the Wiki. The most recent example is in the form/ subdirectory and dated mid 2020. However, when building the file(s) with my ConTeXt distribution the file created is broken, in comparison to the PDF checked in into the Git.

The more obvious difference is that the PDF in the repository can be filled in the Firefox 89 beta, while the other PDF doesn't even display the fields as forms. Running pdfinfo also yields:

...
Syntax Error: Form field child is not a dictionary

I suspect that due to some breakage the forms children aren't set in the AcroForms dictionary anymore? My ConTeXt versions are:

# ArchLinux Repos

context --version mtx-context | ConTeXt Process Management 1.04 mtx-context | mtx-context | main context file: /usr/share/texmf- dist/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2021.03.05 19:11 mtx-context | main context file: /usr/share/texmf- dist/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2021.03.05 19:11

# Debian Buster Repos mtx-context | ConTeXt Process Management 1.02 mtx-context | mtx-context | main context file: /usr/share/texmf/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2018.04.04 00:51

# Docker Image: Current

mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.01.30 14:13 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.01.30 14:13

# Docker Image: Beta mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.01.30 14:13 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.01.30 14:13

# Docker Image: LMTX mtx-context | ConTeXt Process Management 1.04 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2021.04.14 22:58 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkxl/context.mkxl mtx-context | current version: 2021.04.14 22:58

# Docker Image: Beta from 2019-09 mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2019.09.10 20:03 mtx-context | main context file: /context/tex/texmf- context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2019.09.10 20:03

The ConTeXt version of the checked in file on GitHub is (according to pdfinfo):

...
Creator: LuaTeX 1.10 7138 + ConTeXt MkIV 2019.08.20 17:20 Producer: macOS Version 10.14.6 (Build 18G5033) Quartz PDFContext

I also remebered another time were I toyed around with it and indeed that PDF also had broken form field children:

...
Creator: LuaTeX 1.12 7306 + ConTeXt MkIV 2020.03.10 14:44 Producer: LuaTeX-1.12

A broken version that I built locally using the :current IslandOfTeX [2] can be found at [3].

The version difference between the broken and not-broken PDFs hints that the breakage occured between 2019.08.20 and 2019.09.10-beta, while the Debian breackage might be due to a backport(?)

Alternatively, this could just be a mistake on my side?

Cheers Leo König

[1]: https://github.com/fiee/ConTeXt [2]: https://gitlab.com/islandoftex/images/context/ [3]: https://mega.nz/file/ThcghTqb#JqRCSsd59bBbMgTMr3ahaPdU4LPlZd0cpA3ZFBJLJ3A

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Pablo Rodriguez

2 May 2 May

10:48 a.m.

On 5/2/21 12:20 AM, Adam Reviczky wrote:

...

Hi,

I cannot get the signature working either, but almost certain it did work in February this year, as I have done some with MKIV. [...]

Hi Adam, I’m on a Linux computer, so I’m not able to check this now. If the signature isn’t working, you mean that the output PDF document from fields-007.tex cannot be signed with Acrobat DC, don’t you? Sorry for asking the obvious question, but this worked perfectly fine each time I tested.

...

Using the https://live.contextgarden.net/ with (LuaTeX 2.06 20200630 + ConTeXt MkIV 2020.06.30 17:30) looks good, but evince does not display the field.

Evince never displays the signature field, only when signed. BTW, using mupdf-gl to sign the PDF document will mess it, since it has problems to recognize the child object. From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one). Just in case it might help, Pablo -- http://www.ousia.tk

Adam Reviczky

12:16 p.m.

Hi Pablo, First of all, my bad, the test suite example works just fine in Adobe, including with ConTeXt latest. I have messed up my form by overriding the PDF version to 2.0, shouldn't have done that. On the viewers, I cannot recall exactly what I've done earlier in the year, but indeed, most likely I have tried evince after signing it from the command line. From https://gitlab.gnome.org/GNOME/evince/-/issues/143 there is still no support for the signing itself, though okular should have some support. In any case, thanks for the hints (I probably should've done more testing)! Adam On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...

On 5/2/21 12:20 AM, Adam Reviczky wrote:

...
Hi,

I cannot get the signature working either, but almost certain it did work in February this year, as I have done some with MKIV. [...]

Hi Adam,

I’m on a Linux computer, so I’m not able to check this now.

If the signature isn’t working, you mean that the output PDF document from fields-007.tex cannot be signed with Acrobat DC, don’t you?

Sorry for asking the obvious question, but this worked perfectly fine each time I tested.

...
Using the https://live.contextgarden.net/ with (LuaTeX 2.06 20200630 + ConTeXt MkIV 2020.06.30 17:30) looks good, but evince does not display the field.

Evince never displays the signature field, only when signed.

BTW, using mupdf-gl to sign the PDF document will mess it, since it has problems to recognize the child object.

From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

Just in case it might help,

Pablo -- http://www.ousia.tk

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Leonard Janis Robert König

7 Jun 7 Jun

2:43 p.m.

Hi Adam, Hi Pablo, I just noticed your replies, sorry for the late answer!

...

On the viewers, I cannot recall exactly what I've done earlier in the year, but indeed, most likely I have tried evince after signing it from the command line. From https://gitlab.gnome.org/GNOME/evince/-/issues/143 there is still no support for the signing itself, though okular should have some support.

I could sign forms with both okular as well as mupdf just fine, although the behavior is different. The former assumes that the field is already an existing signature and segfaults when you look at the properties, but cann successfully add another signature using the "Tools" menu. With the latter you can click on the form field to trigger a menu to select the signature you want to sign with, and it "replaces" the "empty" signature generated by ConTeXt. Both work fine, even with my newer ConTeXt.

...

On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...
...
Using the https://live.contextgarden.net/ with (LuaTeX 2.06 20200630 + ConTeXt MkIV 2020.06.30 17:30) looks good, but evince does not display the field.

Evince never displays the signature field, only when signed.

BTW, using mupdf-gl to sign the PDF document will mess it, since it has problems to recognize the child object.

From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

As mentioned above, it seems that mupdf (now?) actually rewrites "both" signatures into one, however Okular doesn't. I could, however, isolate the original issue I posted on the ML: Actually forms still work, but they don't, if embedded into TABLEs. Here's a MWE: \setupinteraction[state=start] \definefield[lineField][line][][][] \starttext \bTABLE[] \bTR \bTD \field[lineField] \eTD \eTR \eTABLE \stoptext This produces Syntax Error: Form field child is not a dictionary when you run pdfinfo on it, and Firefox can't properly render the forms either. However, if you comment the lines defining the begin and end of the TABLE, the form is properly displayed in FF and pdfinfo doesn't produce any errors anymore. This was apparently not an issue when the original beschwerdeform.pdf in the form/ subdir of [1] was built, but both my local installation and live.contextgarden.net produce the "faulty" PDF. ~ Leo [1]: https://github.com/fiee/ConTeXt

Pablo Rodriguez

8 Jun 8 Jun

9:41 a.m.

On 6/7/21 10:43 PM, Leonard Janis Robert König wrote:

...

Hi Adam, Hi Pablo,

I just noticed your replies, sorry for the late answer!

I could sign forms with both okular as well as mupdf just fine, although the behavior is different. The former assumes that the field is already an existing signature and segfaults when you look at the properties, but cann successfully add another signature using the "Tools" menu.

Hi Leo, I’m afraid that I don’t use Okular.

...

With the latter you can click on the form field to trigger a menu to select the signature you want to sign with, and it "replaces" the "empty" signature generated by ConTeXt. Both work fine, even with my newer ConTeXt.

mupdf-gl signs the document, but in a way that only mupdf-gl understands it. Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

...

...
On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...
[...] From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

As mentioned above, it seems that mupdf (now?) actually rewrites "both" signatures into one, however Okular doesn't.

Sorry, objects is a very special term in PDF parlance. It has nothing to do with signatures. Just in case it might help, Pablo -- http://www.ousia.tk

Leonard Janis Robert König

3:07 p.m.

On Tue, 2021-06-08 at 17:41 +0200, Pablo Rodriguez wrote:

...

On 6/7/21 10:43 PM, Leonard Janis Robert König wrote:

...
Hi Adam, Hi Pablo,

I just noticed your replies, sorry for the late answer!

I could sign forms with both okular as well as mupdf just fine, although the behavior is different. The former assumes that the field is already an existing signature and segfaults when you look at the properties, but cann successfully add another signature using the "Tools" menu.

Hi Pablo,

...

I’m afraid that I don’t use Okular.

...
With the latter you can click on the form field to trigger a menu to select the signature you want to sign with, and it "replaces" the "empty" signature generated by ConTeXt. Both work fine, even with my newer ConTeXt.

mupdf-gl signs the document, but in a way that only mupdf-gl understands it.

Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

Hm, I tested with Okular, Firefox and MasterPDF as I don't have Acrobat on Linux, and both understand the signature, which is why I thought it'd be correct.

...

...
...
On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...
[...] From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

As mentioned above, it seems that mupdf (now?) actually rewrites "both" signatures into one, however Okular doesn't.

Sorry, objects is a very special term in PDF parlance. It has nothing to do with signatures.

Just in case it might help,

Ah, I see. I'm still a bit unsure what to make of the "fields nested in TABLEs" issue, but maybe further debugging will show at some point. ~ Leo

Adam Reviczky

4:29 p.m.

Not sure how good it is, but in the poppler discussion this site was mentioned to verify the signature details: https://validator.docusign.com/ I have tried using with poppler's pdfsig and Okular. Adam On Tue, Jun 8, 2021 at 10:14 PM Leonard Janis Robert König wrote:

...

On Tue, 2021-06-08 at 17:41 +0200, Pablo Rodriguez wrote:

...
On 6/7/21 10:43 PM, Leonard Janis Robert König wrote:

...
Hi Adam, Hi Pablo,

I just noticed your replies, sorry for the late answer!

I could sign forms with both okular as well as mupdf just fine, although the behavior is different. The former assumes that the field is already an existing signature and segfaults when you look at the properties, but cann successfully add another signature using the "Tools" menu.

Hi Pablo,

...
I’m afraid that I don’t use Okular.

...
With the latter you can click on the form field to trigger a menu to select the signature you want to sign with, and it "replaces" the "empty" signature generated by ConTeXt. Both work fine, even with my newer ConTeXt.

mupdf-gl signs the document, but in a way that only mupdf-gl understands it.

Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

Hm, I tested with Okular, Firefox and MasterPDF as I don't have Acrobat on Linux, and both understand the signature, which is why I thought it'd be correct.

...
...
...
On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...
[...] From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

As mentioned above, it seems that mupdf (now?) actually rewrites "both" signatures into one, however Okular doesn't.

Sorry, objects is a very special term in PDF parlance. It has nothing to do with signatures.

Just in case it might help,

Ah, I see. I'm still a bit unsure what to make of the "fields nested in TABLEs" issue, but maybe further debugging will show at some point.

~ Leo

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Leonard Janis Robert König

9 Jun 9 Jun

4:28 a.m.

On Tue, 2021-06-08 at 23:29 +0100, Adam Reviczky wrote:

...

Not sure how good it is, but in the poppler discussion this site was mentioned to verify the signature details: https://validator.docusign.com/

I have tried using with poppler's pdfsig and Okular.

Oh, that's a great tool, thanks! Leo

...

Adam

On Tue, Jun 8, 2021 at 10:14 PM Leonard Janis Robert König < ljrk@ljrk.org> wrote:

...
...
On 6/7/21 10:43 PM, Leonard Janis Robert König wrote:

...
Hi Adam, Hi Pablo,

I just noticed your replies, sorry for the late answer!

I could sign forms with both okular as well as mupdf just fine, although the behavior is different. The former assumes that the field is already an existing signature and segfaults when you look at

On Tue, 2021-06-08 at 17:41 +0200, Pablo Rodriguez wrote: the

...
...
properties, but cann successfully add another signature using the "Tools" menu.

Hi Pablo,

...
I’m afraid that I don’t use Okular.

...
With the latter you can click on the form field to trigger a menu to select the signature you want to sign with, and it "replaces" the "empty" signature generated by ConTeXt. Both work fine, even with my newer ConTeXt.

mupdf-gl signs the document, but in a way that only mupdf-gl understands it.

Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

Hm, I tested with Okular, Firefox and MasterPDF as I don't have Acrobat on Linux, and both understand the signature, which is why I thought it'd be correct.

...
...
...
On Sun, May 2, 2021 at 5:50 PM Pablo Rodriguez wrote:

...
[...] From my experience, only Acrobat deals with child objects in signatures generating a valid signature (and rewriting the two objects into a single one).

As mentioned above, it seems that mupdf (now?) actually rewrites "both" signatures into one, however Okular doesn't.

Sorry, objects is a very special term in PDF parlance. It has

nothing

...
to do with signatures.

Just in case it might help,

Ah, I see. I'm still a bit unsure what to make of the "fields nested in TABLEs" issue, but maybe further debugging will show at some point.

~ Leo

___________________________________________________________________ __ ______________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________ __ ______________

______________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net _____________________________________________________________________ ______________

Pablo Rodriguez

8:42 a.m.

On 6/9/21 12:28 PM, Leonard Janis Robert König wrote:

...

On Tue, 2021-06-08 at 23:29 +0100, Adam Reviczky wrote:

...
Not sure how good it is, but in the poppler discussion this site was mentioned to verify the signature details: https://validator.docusign.com/

Oh, that's a great tool, thanks!

Many thanks for the link to the tool, Adam. Pablo -- http://www.ousia.tk

Pablo Rodriguez

8:41 a.m.

On 6/8/21 11:07 PM, Leonard Janis Robert König wrote:

...

On Tue, 2021-06-08 at 17:41 +0200, Pablo Rodriguez wrote:

...
[...] Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

Hm, I tested with Okular, Firefox and MasterPDF as I don't have Acrobat on Linux [...]

Hi Leo, Acrobat for Linux is available (although the version is too old) at ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/. Acrobat isn’t able to deal with the signature annotation and with the

...

...
Sorry, objects is a very special term in PDF parlance. It has nothing to do with signatures.

Here is a description: https://www.adobe.com/content/dam/acom/en/devnet/pdf/PDF32000_2008.pdf#searc... (link should work with Firefox). But you might check yourself with the following sample: \setuppapersize[A10, landscape] \setuplayout[page] \setupinteraction[state=start] \starttext \setupfield[sl][horizontal] [frame=on, width=\textwidth, height=\textheight] \definefield[x][signature][sl] \field[x] \stoptext The attached certificate has the password 123456. Only mupdf-gl sees the signature annotation after signing it. Acrobat, Evince, Okular and xpdf cannot deal with the signature. https://validator.docusign.com/ gives a warning: This document doesn't have any digital signatures. I hope it might help, Pablo -- http://www.ousia.tk

Leonard Janis Robert König

8:56 a.m.

On Wed, 2021-06-09 at 16:41 +0200, Pablo Rodriguez wrote:

...

On 6/8/21 11:07 PM, Leonard Janis Robert König wrote:

...
On Tue, 2021-06-08 at 17:41 +0200, Pablo Rodriguez wrote:

...
[...] Try to open a PDF document signed with mupdf-gl in Acrobat (Reader or not). You will see that the signature is wrong.

Hm, I tested with Okular, Firefox and MasterPDF as I don't have Acrobat on Linux [...]

Hi Pablo,

...

Acrobat for Linux is available (although the version is too old) at ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/.

Acrobat isn’t able to deal with the signature annotation and with the

yeah, I try to stay away from this pile of security holes :)

...

...
...
Sorry, objects is a very special term in PDF parlance. It has nothing to do with signatures.

Here is a description: https://www.adobe.com/content/dam/acom/en/devnet/pdf/PDF32000_2008.pdf#searc... (link should work with Firefox).

Thanks a bunch! I wonder why PDF 2.0 still isn't uploaded there, but probably it's now ISO only(?)

...

But you might check yourself with the following sample:

\setuppapersize[A10, landscape] \setuplayout[page] \setupinteraction[state=start] \starttext \setupfield[sl][horizontal] [frame=on, width=\textwidth, height=\textheight] \definefield[x][signature][sl] \field[x] \stoptext

The attached certificate has the password 123456.

Only mupdf-gl sees the signature annotation after signing it. Acrobat, Evince, Okular and xpdf cannot deal with the signature.

On my system (but rather recent, Arch-Testing) Okular did see the signature actually! However the validator doesn't recognize a thing.

...

https://validator.docusign.com/ gives a warning:

This document doesn't have any digital signatures.

I hope it might help,

Luckily(?) I don't have to deal with signatures that much right now, but my problem is more related to other kinds of forms which seems to be able to be worked around by not using TABLE. ~ Leo

Taco Hoekwater

9:05 a.m.

Hi,

...

On 9 Jun 2021, at 16:41, Pablo Rodriguez wrote:

Only mupdf-gl sees the signature annotation after signing it. Acrobat, Evince, Okular and xpdf cannot deal with the signature.

Just FYI: On the Mac, I can sign the processed example using Adobe Acrobat Reader DC, and it can save a signed pdf as well as re-open it, including showing that verification bar that says it is a signed pdf. mupdf-gl ‘sees’ the original field also, but mine is compiled without openssl so it cannot actually sign. It happily correctly opens the signed version from AR DC, of course. Apple Preview does not recognize the signature field (well, it has zero support for signing to begin with, so that is not a surprise). — Taco Hoekwater E: taco@bittext.nl genderfluid (all pronouns)

1143

Age (days ago)

1190

Last active (days ago)

List overview

Download

12 comments

4 participants

participants (4)

Adam Reviczky
Leonard Janis Robert König
Pablo Rodriguez
Taco Hoekwater

PDF forms not creating proper children

tags

participants (4)