[
https://issues.apache.org/jira/browse/PDFBOX-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127443#comment-16127443
]
Tim Allison commented on PDFBOX-3898:
-------------------------------------
from [~msahyoun] on the dev list:
bq. I had a quick look with the debugger and the file looks fine. There is
nothing wrong with a non terminal field having a field type /FT and the kids
(terminal fields) having not. In such case the field type should be taken for
the kids. Which version of PDFBox is Tika 1.14 on?
Tika 1.14 used 2.0.3, but I'm getting the same behavior with PDFBox trunk's
PrintFields.
I think you can see the problem here in PrintFields via the debugger:
{noformat}
if (field instanceof PDNonTerminalField)
{
...
handle the kids
}
else
{
...don't look for kids
}
{noformat}
The parent/root field is a PDTextField, which as you know is a
PDTerminalField...in short, we never call getKids() on the PDTextField
> AcroFields' PDTextField (and others?) can have kids
> ---------------------------------------------------
>
> Key: PDFBOX-3898
> URL: https://issues.apache.org/jira/browse/PDFBOX-3898
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Tim Allison
>
> On TIKA-2442, [~ccreutzig] submitted a PDF file that shows that a PDTextField
> can have Kids. According to the PDF spec version 1.7, table 8.69, page 675,
> "Kids" is (apparently) available for all fields. In the description of a
> Text field, the spec says
> bq. Besides the usual entries common to all fields (see Table 8.69 on page
> 675) and to fields containing variable text (see Table 8.71)
> Acrobat is able to handle the triggering file, and when modified and saved,
> Acrobat maintains the parent field as a PDTextField.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
