Re: [Podofo-users] PDF Forms with non-standard annotations

[Leonard R. <lro...@ad...>]

The FT key can be inherited from it's parent when they are organized in a hierarchy (ISO 32000-1, 12.7.3.1).

Yes, checking the Subtype is the correct way to identify a form field. HOWEVER, you should probably also look at adding inheritance support (as a generalization) to some/all of the field related APIs.

Leonard

From: Dennis Jenkins <den...@gm...<mailto:den...@gm...>>
Date: Thursday, April 24, 2014 at 11:51 PM
To: "pod...@li...<mailto:pod...@li...>" <pod...@li...<mailto:pod...@li...>>
Subject: [Podofo-users] PDF Forms with non-standard annotations

Hello,

    I am using PoDoFo in a project to fill-in a variety of US tax forms, such as the US Federal 941 form and the Arizona A1-QRT.  I'm running into a problem with the A1-QRT form [1] using PoDoFo to access all of the form fields.

    According to PoDoFo, page #0 contains 26 form fields.  However, the page/form actually has 34 fields.  I dug into the code in PoDoFo for PdfPage::GetNumFields() and wrote a small program to dump all of the annotations for a given page of a pdf.  The 34 annotations are all type "ePdfAnnotation_Widget", but only 26 has a dictionary key "FT", per the spec (ISO 32000:2008, section 12.7.3.1).  The other 8 fields lack this dictionary key.  Yet in "Adobe Reader XI", the form is fully functional and all 34 fields are operable.

   You can see the difference in PoDoFo-Browser.  Annotations 0 through 6 all have an 'FT' key and are text fields.  The next three are check boxes and lack the "FT" key.

   Of course, I can bypass "PdfPage::GetField()" and roll my own, but before doing so, I wanted to present my findings and ask:

1) How do these form fields work in Adobe Reader if they lack the "FT" key?

2) Should PoDoFo be changed to not require the presence of the "FT" key and simply accept the presence of the "/n Subtype = /Widget" to indicate a form field?

    Thank you for your time.



[1] http://www.azdor.gov/Forms/Withholding.aspx