[
https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun reassigned PDFBOX-5735:
--------------------------------------
Assignee: Maruan Sahyoun
> Set the default value for PDNonTerminalField
> --------------------------------------------
>
> Key: PDFBOX-5735
> URL: https://issues.apache.org/jira/browse/PDFBOX-5735
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
> Affects Versions: 2.0.30, 3.0.1 PDFBox
> Reporter: Maruan Sahyoun
> Assignee: Maruan Sahyoun
> Priority: Minor
>
> From the mailing list:
> {quote}
> Hi there!
> I was glancing through the code to PDFBox 3.0.1 to better grok PDF form
> fields/widgets and the hierarchical way they are organized and I ran
> across something that might be a bug in the code.
> Or... it might just be my lack of understanding of how PDF default
> values work in non-terminal field objects. At the very least I found it
> surprising and different from the code in other types of PDField
> subclasses. So I decided to bring it up here on the dev mailing list.
> In the PDNonTerminalField.java file, the setDefaultValue() method logic
> looks like this [1]:
> getCOSObject().setItem(COSName.V, value);
> It appears to set the value of the COSName.V item... while the
> getDefaultValue() method in the class (and the setDefaultValue() methods
> in other PDField subclasses that I checked) use the COSName.DV value as
> expected.
> Is this a bug, or is this intentional?
> Thank you for your time,
> - Dwayne
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
