Repository navigation
insert_file(...) breaks radio button groups #5055
Description
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
Activity
JorjMcKie commentedon Jul 23, 2026
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():/Kidsof a/Parentfield which is the owner of the field name (/Tkey) and other properties. This/Parentobject is the one stored in theAcroForm/Fieldsarray in the PDF catalog. ==> supported/Parentbut do contain a field name/Tthemselves. RadioButtons with the same/Tvalue define the RBG. Exactly one of these widgets must be contained in the mentionedAcroForm/Fieldsarray. This is your case. ==> not yet supportedWe 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 commentedon Jul 24, 2026
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 commentedon Jul 24, 2026
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 ...
JorjMcKie commentedon Oct 4, 2026
A new
Pagemethod.repair_flat_rbgs()spots and converts so-called "flat" Radio Button Groups to the standard format.The method is generally available (independent of method
.insert_pdf()). It is however executed under the hood ifDocument.insert_pdf(source, widgets=True)and thesourcePDF contains form fields.julian-smith-artifex-com commentedon Oct 19, 2026
Fixed in PyMuPDF-2.0.