[ https://issues.apache.org/jira/browse/PDFBOX-5735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maruan Sahyoun resolved PDFBOX-5735. ------------------------------------ Resolution: Fixed fixed - thank you for the report > 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 > Fix For: 2.0.31, 3.0.2 PDFBox, 4.0.0 > > > 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