![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 3/9/2016 4:39 PM, Alan BRASLAU wrote:
One has to be EXTREMELY careful with these "features".
Currently, there are so-called PDF forms, but they are far from fully functional. I suspect that the specifications are not clear and are not respected in any case.
which is usually the case with all these widget things (and i suspect that in the end the specs or behaviour are determined by what got implemented)
I will give a concrete example: The American Tax agency, IRS, provides a large number of PDF forms that can be filled out, for they LOVE forms. One can use Acrobat (Reader or Pro) and one can even fill them out using evince. Yeah! However, whereas the forms filled-out using evince can be saved and re-edited, printed, etc., opening these filled-out forms in Acrobat come out blank. (Luckily I was able to provide my accountant with *printed*, filled-in copies, both paper and PDF.)
oh, so there are free viewers that can do it? do they also support the javascript stuff that is related (e.g. for checking fields and so?)
Other examples are forms that can ONLY be read using the latest and greatest Acrobat. The situation is problematic, and I know of at least one government agency that has finally turned towards a web-based reporting method as they had received multiple complaints and even legal challenges on their Adobe/PDF only reporting method used previously.
This can explain Hans' reticence towards reverse engineering in absence of clear, published specifications that are indeed respected.
indeed
Alan
On Wed, 9 Mar 2016 16:16:24 +0100 Hans Hagen
wrote: On 3/9/2016 2:11 PM, Andreas Schneider wrote:
Hello all,
is there currently any mechanism in ConTeXt similar to the LaTeX digsig or eforms package? I want to add a form field that can be digitally signed (which is now already possible with Acrobat Reader, not just with Acrobat Pro).
Additionally (like the mentioned eforms package) it would be nice, if you could specify other form fields that should be locked once the signature field is actually signed (according to the PDF spec this is simply set via a dictionary).
it's probably something trivial to implement so what are the relevant fields (paragraphs/tables/dics/fields in the pdf spec) .. i'm not going to reverse engineer some package but start from the spec
Anyway: can this currently be achieved with ConTeXt? If not: is there any chance to get that feature added sometime? :-)
so far i never bothered with anything signature (i must say that i never ran into such docs and it would not make them more valid to me anyway)
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://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------