Interactive form (AcroForm) support

[timvandermeij]

This is a tracking issue only, so this is not the place for any other questions or discussions. Open a new issue for that.

This is a meta issue for interactive form (AcroForm) support according to Chapter 12.7 of the PDF reference (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.2110737). This includes all form elements except for signature fields, which are tracked in #1076. The objective is to get https://github.com/mozilla/pdf.js/blob/master/test/pdfs/f1040.pdf.link to render completely, but also to resolve other open issues and PRs.

General

• Prepare core and display layer for implementing form elements (Improve the structure for widget annotations #7596)
• Reference testing (Render interactive form (AcroForm) text widget annotations #7602)
• Preference (Render interactive form (AcroForm) text widget annotations #7602)
• Remove global PDFJS.renderInteractiveForms usage (Interactive forms: remove global PDFJS usage #7640)
• Refactor field name construction code in WidgetAnnotation (Widget annotation: implement field name according to the specification #7775)
• Refactor or clarify where annotations are rendered
  • Mostly in the display layer, but text widget annotations with appearance streams are rendered in the core layer, which causes confusion...
• Appearances
• Storing entered values for when the page is destroyed when it is not visible
• Printing entered values
  • Either print the HTML elements or render the contents onto the canvas (use appendToOperatorList)
• Enable by default
• Update the example (Interactive forms: rewrite AcroForms example #8030)
• Add Firefox pref to enable/disable forms (https://bugzilla.mozilla.org/show_bug.cgi?id=1652145)

Text widgets

• Rendering of single-line fields (Render interactive form (AcroForm) text widget annotations #7602)
• Handle maximum length (Text widget annotations: implement maximum length and text alignment #7622)
• Handle flags: multiline and read-only (Text widget annotations: support read-only/multiline fields and improve testing #7633)
• Handle flags: comb (Text widget annotations: implement comb support #7649)
• Handle justification (Text widget annotations: implement maximum length and text alignment #7622)
• Sanitize maxLen and textAlignment in the core layer and unit tests for this (Text widget annotations: implement unit testing and sanitize data values #7629)

Choice widgets

• Rendering of combo boxes (Interactive forms: render choice widget annotations #7671)
• Rendering of list boxes (Interactive forms: render choice widget annotations #7671)

Button widgets

• Rendering of pushbuttons (Button widget annotations: implement support for pushbuttons #9191)
• Rendering of checkboxes (Interactive forms: render button widget annotations (checkboxes and radio buttons) #7898)
• Rendering of radio buttons (Interactive forms: render button widget annotations (checkboxes and radio buttons) #7898)

[Snuffleupagus]

This is a meta issue for tracking interactive form (AcroForm) support according to Chapter 8.6 of the PDF reference (https://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf#page=671&zoom=auto,-246,244).

It might be a good idea to instead base the work on the latest version of the PDF specification, just in case there are any differences: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.2110737.

Also, perhaps a good idea to add a "General" TODO item about ensuring proper test-coverage?

[timvandermeij]

Both items have been addressed. Thank you!

[Snuffleupagus]

I think that we're also going the have to actually parse the contents of the AcroForm dictionary, since otherwise we're not able to e.g. load all the necessary font resources.
Obviously, we cannot use custom fonts in the display layer, but we should be able to at least infer the correct font-family (and things like e.g. bold/italic) that should be used and pass that info on to the display layer.

Also, for printing forms, we might be able to utilize (or build upon) the already existing appendToOperatorList functionality, but that will definitely require that font resources present in the AcroForm dictionary has been loaded.

Another thing that we probably should attempt to support, is using the correct text colour in the display layer (note how in Adobe Reader the text in the form fields of f1040.pdf is blue). This probably ties in to better and more complete Appearance stream support.

Finally, a general question: Will we actually be able to support forms in a meaningful way, without partial (and well sanitized) script support?

[timvandermeij]

Good points. I just added them to the item list above. I don't think we really need script support as the AcroForms generally just require filling and printing. AFAIK scripts are only used for interaction between elements, but we can implement the most used functionality ourselves (such as resetting the form or button actions for printing it). We'll have to see how widely used such script functionality is.