[
https://issues.apache.org/jira/browse/PDFBOX-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904016#comment-16904016
]
Tilman Hausherr commented on PDFBOX-4617:
-----------------------------------------
I'm in favor of doing it like Adobe... We could also have an additional
low-level index-based method (or make updateByValue() public?)
Or can't the whole thing avoided if the "Opt" array doesn't contain "0",
instead only Choice1 and Choice2?
> 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-2019-08-05.pdf, 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}
> java.lang.IllegalArgumentException: value '4' is not a valid option for the
> field RadiosDuplicateExportValues, valid values are: [0, Choice2] 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 "Choice2" or "0" 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]
