Bug 442849

Summary: PDF form option button choice does not display
Product: [Applications] okular Reporter: Brenton Chapin <bzipitidoo>
Component: PDF backendAssignee: Okular developers <okular-devel>
Status: CONFIRMED ---    
Severity: normal CC: kossebau, nate, psychonaut
Priority: NOR    
Version First Reported In: 21.08.1   
Target Milestone: ---   
Platform: unspecified   
OS: All   
See Also: https://bugs.kde.org/show_bug.cgi?id=343834
https://bugs.kde.org/show_bug.cgi?id=431792
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: PDF form with option buttons.
LibreOffice Writer document with forms, from which the PDF was created.

Description Brenton Chapin 2021-09-23 15:59:10 UTC
Created attachment 141829 [details]
PDF form with option buttons.

Okular will not display or print the choice made in option buttons (radio buttons) in a PDF form.

Okular will accept and record a choice.  Toggling the "Show Forms" button will show which button was chosen.  But when "Show Forms" is off, the choice is invisible.  The choice is still invisible in Print Preview, and in print.

I see the same problem in Evince.

The simple test file I attached shows the problem.  It works correctly in Firefox.  (However, Firefox has trouble with more complicated PDF forms.)  Of the free tools I tried (Okular, Evince, PDF Shuffler/PDF Arranger, Xournal, Firefox, Chrome), only Chrome was able to handle the more complicated form correctly.
Comment 1 Brenton Chapin 2021-09-25 18:33:06 UTC
Created attachment 141906 [details]
LibreOffice Writer document with forms, from which the PDF was created.
Comment 2 Friedrich W. H. Kossebau 2025-12-30 17:32:15 UTC
Could confirm the experience. Then also can hint to the cause and a solution:

AFAIK  the radio button marks in PDFs can be optionally styled using glpyhs from the Zapf Dingbats (compatible) typeface/font. Zapf Dingbats being one of typefaces the PDF spec expects to be provided by a PDF rendering software. Poppler/Okular here relies on the distribution to provide such fonts on the system. iIf such font though is not installed on the system, the poppler render backend used by Okular will just skip the rendering of the mark. The default unstyled radio mark seems rendered by poppler at least in current version directly by a drawCircle command. So the reported bug only happens with custom styled radio button marks, like LibreOffice seems to inject.

Thus the fix here is to install a Zapf Dingbats compatible font on the system, On openSUSE TW installing the package urw-base35-fonts-D050000L, providing font D050000L from the URW font set, makes the radio mark appear also with the provided example.

Ideally your distribution would ensure there is a dependency of the poppler package on fonts which match the typefaces expected to exist, See for a similar issue around checkbox this email: https://mail.kde.org/pipermail/distributions/2025-December/001657.html

IMHO poppler/Okular should make some noise though if there is no Zapf Dingbats compatible typeface around,  instead of just blanking out and making it look just as if no option (or checkbox) is chosen/checked.