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). Anyway: can this currently be achieved with ConTeXt? If not: is there any chance to get that feature added sometime? :-) Best regards Andreas
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) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
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.
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.)
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.
Alan
On Wed, 9 Mar 2016 16:16:24 +0100
Hans Hagen
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)
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 -----------------------------------------------------------------
Very good point(s). Just for more reference: We use such forms heavily in-house, sometimes with a multi-stage approach. Example: the employee fills out his details, etc., and signs that part. The fields he had to fill are now locked (but saved, ofcourse ;-)). That PDF is now sent to his or her boss, who fills out the organisational details, and signs that part. Finally the PDF goes to HR or whoever who gives the final signature. Since all employees have signature cards (chips with PKCS signatures on them) the whole process get's safe, accountable and paper-free. In the past stuff like this required printing, hand-signing, scanning, sending, printing-again, ... you get the idea. These forms are currently handcrafted using Acrobat. I will analyse the resulting PDF streams, try to match that against the PDF spec and what the eforms-package does. If that lines up, I'll provide the necessary details here. Thank you Hans and Alan! :-) Am 2016-03-09 16:39, schrieb Alan BRASLAU:
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.
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.)
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.
Alan
Am 2016-03-09 um 22:04 schrieb Andreas Schneider
Very good point(s).
Just for more reference: We use such forms heavily in-house, sometimes with a multi-stage approach. Example: the employee fills out his details, etc., and signs that part. The fields he had to fill are now locked (but saved, ofcourse ;-)). That PDF is now sent to his or her boss, who fills out the organisational details, and signs that part. Finally the PDF goes to HR or whoever who gives the final signature. Since all employees have signature cards (chips with PKCS signatures on them) the whole process get's safe, accountable and paper-free. In the past stuff like this required printing, hand-signing, scanning, sending, printing-again, ... you get the idea. These forms are currently handcrafted using Acrobat.
I will analyse the resulting PDF streams, try to match that against the PDF spec and what the eforms-package does. If that lines up, I'll provide the necessary details here.
You can already create the forms with ConTeXt and then extend them with Acrobat - that’s at least a lot less work. I’m not up-to-date WRT PDF specs, previously all the signature stuff wasn’t in a public spec. But if there exists a LaTeX package, it can’t be that hard any more. I recently created forms for a kindergarten patron foundation - parents have to fill more than 50 pages of forms, each in two copies, for all the necessary details and responsibilities. Most of the fields are used several times (name and birthday of the child, name and address of the kindergarten etc.) Because it was easy, I made interactive forms and suggested to evaluate them with a script that transfers the data into a database. Unfortunately, the teachers seem to be computer illiterate, they want to fill out everything manually (or have the parents do it). Maybe they’re just sadomasochists. Greetlings, Hraban --- http://www.fiee.net http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
Hello Hans, after comparing eforms and the result of a document edited by Acrobat, the relevant portions in the spec (PDF 32000-1:2008) are: Section 12.7.4.5, with tables 232 and 233. From what I see it should be possible to add a field /FT /Sig with and without a /Lock dictionary. The /Lock dictionary created by Acrobat also specifies the optional /Type /SigFieldLock (eforms doesn't, but when in doubt, I trust Adobe more than eforms ;-)) Here is an example from the PDF stream of a document manually forged with Acrobat: %% Object stream: object 167, index 37; original object ID: 475 << /AP << /N 188 0 R
/DA (/Helv 0 Tf 0 g) /F 4 /FT /Sig /Lock 187 0 R /MK <<
/P 196 0 R /Rect [ 253.965 163.306 525.056 186.143 ] /Subtype /Widget /T (Gehnehmiger Unterschrift) /Type /Annot
%% Object stream: object 187, index 57; original object ID: 495 << /Action /Exclude /Fields [ (Einrichter Name) (Einrichters Unterschrift) ] /Type /SigFieldLock
("Einrichter Name" is another Text Field --> /FT /Tx [...] /Subtype /Widget [...] /T (Einrichter Name) "Einrichters Unterschrift" is another Signature Field) Best regards Andreas Am 2016-03-09 16:16, schrieb Hans Hagen:
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)
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 3/10/2016 11:04 AM, Andreas Schneider wrote:
Hello Hans,
after comparing eforms and the result of a document edited by Acrobat, the relevant portions in the spec (PDF 32000-1:2008) are: Section 12.7.4.5, with tables 232 and 233.
From what I see it should be possible to add a field /FT /Sig with and without a /Lock dictionary. The /Lock dictionary created by Acrobat also specifies the optional /Type /SigFieldLock (eforms doesn't, but when in doubt, I trust Adobe more than eforms ;-))
Here is an example from the PDF stream of a document manually forged with Acrobat: %% Object stream: object 167, index 37; original object ID: 475 << /AP << /N 188 0 R
/DA (/Helv 0 Tf 0 g) /F 4 /FT /Sig /Lock 187 0 R /MK <<
/P 196 0 R /Rect [ 253.965 163.306 525.056 186.143 ] /Subtype /Widget /T (Gehnehmiger Unterschrift) /Type /Annot
%% Object stream: object 187, index 57; original object ID: 495 << /Action /Exclude /Fields [ (Einrichter Name) (Einrichters Unterschrift) ] /Type /SigFieldLock
("Einrichter Name" is another Text Field --> /FT /Tx [...] /Subtype /Widget [...] /T (Einrichter Name) "Einrichters Unterschrift" is another Signature Field)
next beta: \setupinteraction[state=start] \starttext \definefield[x][signature] \field[x] \stoptext
Am 2016-03-09 16:16, schrieb Hans Hagen:
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)
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
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 -----------------------------------------------------------------
participants (4)
-
Alan BRASLAU
-
Andreas Schneider
-
Hans Hagen
-
Henning Hraban Ramm