insert_file(...) breaks radio button groups

[Patschke]

Description of the bug

While the documentation states

PyMuPDF does not currently support the creation of groups of (interconnected) radio buttons

I was expecting to be able to append files with radio buttons in them. However, this seems to break the button groups. The resulting mwe_out.pdf has broken radio buttons in them: Depending on the pdf viewer, it is broken in different ways. Using evince, you can click each button only once, before it stops working. Using firefox, the 2nd button is stuck if you click it, while the other 4 keep working.

I'm not sure if this is a bug in PyMuPDF, in MuPDF, or expected behaviour in terms of limited radio-button compatibility.

How to reproduce the bug

I've put together a MWE (or rather: minimal-failing-example?). A minimalistic mwe.pdf generated using LaTeX mwe.tex with a set of 5 radio buttons and 4 lines of python code mwe.py: It opens the pdf, insert_file(...)s it into another (empty) pdf and saves the result.

PyMuPDF version

1.28.0

Operating system

Linux

Python version

3.14

[JorjMcKie]

Thank you for the submission and confirming your observation.
Unfortunately, the are multiple ways to achieve this RBG behavior and we yet support only one of them via methods .insert_file()/.insert_pdf():

1. RadioButton widgets are /Kids of a /Parent field which is the owner of the field name (/T key) and other properties. This /Parent object is the one stored in the AcroForm/Fields array in the PDF catalog. ==> supported
2. RadioButton widgets have no /Parent but do contain a field name /T themselves. RadioButtons with the same /T value define the RBG. Exactly one of these widgets must be contained in the mentioned AcroForm/Fields array. This is your case. ==> not yet supported
3. The RBG logic is implemented programmatically using JavaScript snippets stored in the widgets. We do not support this but it may or may not work, depending on the making of the programmed logic. ==> not supported

We will see what we can do to include alternative 2 in our logic in one of our next releases.
As far as alternative 3 is concerned I am more pessimistic. Using JS makes it possible to achieve RBG-like behavior for other widget types than RadioButtons, like check boxes. Things can quickly become ugly here ...

[Patschke]

Thanks for the response. If I understand correctly, option 1 is what the PDF specs (ISO 32000-2:2020) state how radio buttons should be handled, while option 2 is what LaTeX+hyperref does? Or are both options according to spec, but only one of them currently handled by PyMuPDF?

While I'd certainly appreciate if (Py)MuPDF could handle option 2 (as many pdf viewers are capable to do so), I fully understand if you decide to follow just the specs and ignore non-standard ways. Perhaps this should be raised as issue with hyperref instead, in order to have them create proper RBG - and maybe it actually was raised as an issue some 10 years ago there latex3/hyperref#3.

[JorjMcKie]

Option 2 does not seem to be outspokenly against the specs. After all it works and it is visibly an easier way to create RBGs.
So I think it is worthwhile to support this ...