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