Am Dienstag, dem 28.05.2024 um 18:13 +0200 schrieb Tilman Hausherr: > > On 28.05.2024 17:27, Martin Resch wrote: > > > > > > Hi Tilman, > > > > thanks a lot for the analysis! > > > > So I am assuming correct that you will raise a bug ticket? > > > > https://issues.apache.org/jira/browse/PDFBOX-5831 > > I'll wait a day or two because I'm not the acroform guy, and then > I'll fix it myself. > > > > > I am not the creator of this PDF. We have to deal with the official > > PDFs provided by the government institution that you mentioned. > > More PDFs can be found here: > > https://www.bundesfreiwilligendienst.de/service/downloads > > Hope that they haven’t more that fishy PDFs published. > > > > > > > > > > I changed the PDF so that the /Opt entry has "A" and "B" instead > > > of "1" and "2" and then it works. > > > > > > > For my knowledge in the meantime for a potential workaround: how > > did you do that? > > > > I edited the PDF with NOTEPAD++. But it should also be able this way: > > field.setExportValues(List.of("A", "B")); > > the field must be cast to a PDRadioButton. However I noticed that > after doing this change, I was no longer able to edit it with Adobe > Reader. > > Another problem is that I get a sort of error message: > > > This might be because of UR3 usage rights signature.
to avoid that an incremental save should be used > > > Tilman > > > > > > > > > > > > > > > > > Best regards > > Martin > > > > > > > > > > > > Am 28.05.2024 um 05:24 schrieb Tilman Hausherr > > > <thaush...@t-online.de>: > > > > > > On 27.05.2024 21:01, Tilman Hausherr wrote: > > > > > > > > > > > I'll have another look tomorrow when I'm more awake. I just > > > > looked and it happens like you wrote. I traced through the code > > > > and it seemed to work properly, i.e. going through different > > > > paths for "1" and "2" (looking for dictionary elements 0 and 1) > > > > but the result was always the same which contradicts the > > > > observation, but that is the fascination in debugging. > > > > > > > > > > I had another look. The values from the /Opt entry are 1 and 2, > > > the values at the dictionary level are 0 and 1. Our software > > > somehow gets confused when 1 is used because it appears in both: > > > when the value "1" is set, then PDButton.updateByOption() is > > > called twice (!!!), once with value 1 and once with 2. > > > > > > I changed the PDF so that the /Opt entry has "A" and "B" instead > > > of "1" and "2" and then it works. > > > > > > So I'd say it's a PDFBox bug. The good thing is that the > > > copyright of that PDF would be with a government institution > > > (BAFzA) so we can use it as a test. > > > > > > Are you the creator of that PDF? > > > > > > Tilman > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > > > > > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
