[
https://issues.apache.org/jira/browse/PDFBOX-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899631#comment-16899631
]
Maruan Sahyoun commented on PDFBOX-4617:
----------------------------------------
I did a little test with Acrobat and setting/getting the values programatically
- setting the value to {{Off}} deselects all options and returns {{Off}}
- setting the Value to {{Choice2}} enables the first option and retuns
{{Choice2}}
- setting the Value to {{0}} enables the third option and retuns {{0}}
- setting a numeric value 1-4 enables the option which is the accoding index in
the list and returns either {{0}} or {{Choice2}}
- one can not set the first option by passing {{0}} as this is conflicting with
the oprion value of {{0}}, passing {{0}} selects the third option and return
{{0}}
Now this is also be not very intuitive.
We could either implement the same behaviour or have a low level value
setting/getting (which uses the 0 based index) and an option based value
setting/getting which uses - in this case - Off, 0, Choice2.
In addition - for the sample form - I'd think that the field should have select
in unison enabled as but that's a different question and not related to the
issue.
WDYT?
> PDButton.setValue and PDButton.getOnValueForWidget cannot handle radios with
> duplicate names and choices
> --------------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-4617
> URL: https://issues.apache.org/jira/browse/PDFBOX-4617
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
> Affects Versions: 2.0.16
> Reporter: Rosalind Douglas
> Priority: Major
> Attachments: Radio buttons with duplicate names and choices.pdf
>
>
> Hello, thank you for all of your efforts in building and maintaining PDFBox.
> We use it extensively for parsing PDFs, programmatically setting values and
> flattening PDFs for print.
> BUG: When we parse the attached PDF, the onvalues for the radio buttons are
> 0, 1, 2, 3, 4, which are determined by PDButton.getOnValueForWidget. Later
> on, when we try to programmatically set the value of the radio buttons
> (PDField.setValue) using the above onvalues, we receive this error:
> {code:java}
> 2019-07-31 08:59:36 ERROR (Prism.java:3744)- STACK:
> java.lang.IllegalArgumentException: value '1' is not a valid option for the
> field radio1, valid values are: [no, yes] and Off at
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.checkValue(PDButton.java:376)
> ~[pdfbox-2.0.16.jar:2.0.16] at
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.setValue(PDButton.java:158)
> ~[pdfbox-2.0.16.jar:2.0.16]
> {code}
> The radio buttons all have the same name, with either "yes" or "no" as the
> choice value. We would expect it to behave like Adobe DC, which allows the
> user to select any of the buttons regardless of whether they have the same
> choice or not. I am on PDFBox 2.0.16.
> Though my example might seem trivial, it's very easy for our PDF creating
> users to do this because copying and pasting fields is the easiest way to
> build a PDF.
> PROPOSED FIX:
> This might be a regression caused by PDFBOX-3391. In our code, we have
> overridden the PDButton.setValue method so that it always invokes
> updateByValue(value) rather than sometimes using updateByOption(value). Here
> is the code that works for us, from PDButton.setValue(String value):
>
> {code:java}
> @Override public void setValue(String value) throws IOException {
> checkValue(value);
> updateByValue(value);
> applyChange(); }
> {code}
>
> One caveat is that the change would probably break your PDFBOX-3391 fix, but
> perhaps there's some way to have them live side by side. I don't know very
> much about the other problem.
> Thanks again,
> Rosalind
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
