Hi JP,
On Mon, May 25, 2026 at 22:30 (+0200), Jean-Pierre Delange via ntg-context
wrote:
> Jim,
> I made a few controlled tests with a minimal ConTeXt example containing only
> radio fields.
> Results:
> * the PDF compiles correctly;
> * the radio widgets are present;
> * Acrobat displays them correctly;
> * the radio logic works correctly (mutual exclusion);
> * the selected value survives save/reopen correctly;
> * TeXworks displays the widgets only partially (generic square fields);
> however, physical printing and “Microsoft Print to PDF” both lose
> the selected radio state completely: only empty squares are printed.
That is pretty much what I have been seeing under Linux (minus the
TeXworks).
> Interestingly, ordinary checkboxes do not seem to suffer from the same
> problem.
No they don't: the text line, text box and checkboxes behave nicely for me.
> This suggests that the issue is probably not the field value itself, nor
> the widget definition, but rather the printable appearance stream (/AP?)
> associated with radio-button states.
> So the current hypothesis would be:
> * the interactive state exists and is correctly stored;
> * Acrobat can render it interactively on screen;
> but the printable appearance for the selected radio state is either
> missing or not honoured during printing.
> One possible next step would be to inspect the PDF appearance dictionaries
> (|/AP|) with tools such as |mutool|, |qpdf|, or similar PDF-inspection
> utilities.
I went brute force and uncompressed some PDFs (including one I made with
libre office which seems to work) and looked at the file directly. I saw
some new-to-me things, but came away unenlightened.
> My understanding is that |/AP| contains the appearance streams used to
> render and print form widgets. So the interesting question would be whether
> the selected radio states actually have corresponding printable appearances
> defined there.
> That might help determine why:
> * the selected state is displayed correctly on screen,
> * survives save/reopen correctly,
> * but disappears entirely when printing.
> In any case, there are people on this list who really know how to dissect
> the mysteries hidden inside PDF internals. I suspect someone will
> eventually shine some light on what is happening here.
I am hoping someone already very familiar with PDF internals will enlighten
me. (And all the other people (you? ;-) who are interested.)
> I am attaching the MWE used for testing.
Thanks again.
Jim
> Le 25/05/2026 à 21:35, Jim via ntg-context a écrit :
>> Hi JP,
>> On Mon, May 25, 2026 at 19:17 (+0200), Jean-Pierre Delange via ntg-context
>> wrote:
>>> Hi Jim,
>>> This is probably not just a “you” problem. Radio buttons are among the least
>>> portable PDF form widgets. Text fields and check boxes often print correctly
>>> because their visible appearance is simpler, while radio buttons depend on
>>> the selected widget’s appearance stream being updated and honoured by the
>>> PDF viewer/printer. First thing to test: make sure the radio setup uses
>>> > option=printable|, and try the |framed| variant in the second optional
>>> argument of |\setupfield|, e.g.
>>> > \setupfield[MMradio][framed][option=printable,...]|.
>> Unfortunately, that did not help. When I saw that I was missing
>> "option=printable" I got hopeful, but alas...
>> I don't see any difference with the [framed] option or changing my
>> frame=off to frame=on. Or doing both.
>>> If that still fails, the robust workaround is to avoid live radio widgets in
>>> the printable version:
>> That seems like I may end up doing that. But here is an interesting
>> thing... For testing on other computers/OS/versions/... I sent the document
>> to someone who uses WordPerfect. (Yes, I'm not kidding.) A few minutes
>> ago he sent me back a copy of my document which he says he created with
>> Wordperfect; it appears to be a straight copy and paste, with the
>> formatting almost identical, but with LM replaced by some "typical" windows
>> fonts. While my ancient version of Acroread wouldn't open the file,
>> firefox would and when I printed it from firefox, the selected radio button
>> actually showed up selected.
>> This makes me think that getting radio buttons isn't completely out of
>> reach.
>>> either flatten the PDF after filling it, or generate a non-interactive
>>> print version using ordinary ConTeXt symbols/frames instead of PDF form
>>> widgets.
>> I am thinking the latter might be the way to go. The forms are for people
>> in an organization which is not associated with more than "average"
>> computer literacy, and I think explaining flattening to people might be
>> confusing. (It is a group of woodworkers, and telling woodworkers to
>> flatten something will have them running to their shops looking for a hand
>> plane.)
>> Originally I had three check boxes, which was not great, because no doubt
>> someone will, some time, check two or there of them. When I came across
>> the radio buttons I thought that was exactly what I wanted.
>>> Your radio field is missing |option=printable|, while your line field has
>>> it. I would also define and place the hidden default button, because
>>> |checkedButton| is used as the initial value but is not defined as a
>>> subfield in the example. Finally, I would remove
>>> |background=screen| while testing print output.
>> Thanks for taking the time to give me these suggestions. Unfortunately,
>> none of them convinced the PDFs to behave.
>>> Radio buttons are fragile across PDF viewers because their printed state
>>> depends on the widget appearance streams being honoured by the
>>> viewer/printer.
>> Indeed, very fragile. Part of me wonders whether there is an issue with
>> the dot I see when I select a radio button... I wonder if there is
>> something in the PDF to print a character, but the character is missing
>> from the fonts in the document. I guess I'll take a look at that now,
>> which gets me into dissecting PDFs, an occupation which I have little skill
>> in.
>> Cheers.
>> Jim
>>> Best//JP
>>> A testable MWE might be this one :
>>> \setupinteraction[state=start]
>>> \starttext
>>> \setupfield
>>> [setup_1]
>>> [reset, horizontal]
>>> [option=printable,
>>> frame=off,
>>> bottomframe=on,
>>> width=4in,
>>> height=1.2em,
>>> offset=-1pt,
>>> frameoffset=2pt]
>>> \definefield[line_1][line][setup_1][][]
>>> This is an input line: \field[line_1]
>>> \blank
>>> \setupfield
>>> [setup_2]
>>> [option=printable,
>>> width=1.2em,
>>> height=1.2em]
>>> \definefield[check_2][check][setup_2][X,_][_]
>>> Click this to see an “X” or check-mark: \field[check_2]
>>> \blank
>>> \setupfield
>>> [setup_3]
>>> [option=printable,
>>> width=1.2em,
>>> height=1.2em,
>>> frame=on]
>>> \definefield
>>> [radio_3]
>>> [radio]
>>> [setup_3]
>>> [checkedButton,Aaa,Bbb,Ccc]
>>> [checkedButton]
>>> \definesubfield[checkedButton][][circle]
>>> \definesubfield[Aaa][][circle]
>>> \definesubfield[Bbb][][circle]
>>> \definesubfield[Ccc][][circle]
>>> % Hidden default radio button:
>>> \hbox to 0pt{\field[checkedButton]\hss}
>>> Aaa \field[Aaa]
>>> Bbb \field[Bbb]
>>> Ccc \field[Ccc]
>>> \stoptext
>>> Le 25/05/2026 à 17:13, Jim via ntg-context a écrit :
>>> > Hi all,
>>> > I have attached a minimal non-working example .tex file and the resulting
>>> > PDF.
>>> > If I type something in the text input line, and/or click the check box,
>>> > when I print the file (from a variety of web browsers and versions of
>>> > Acrobat reader on Linux and windows) those show up in the printout (or the
>>> > "print to file" file).
>>> > However, if I select a radio button, while on screen the button is visibly
>>> > selected, but in the printout (or "print to file" file) the button is not
>>> > selected.
>>> > I understand (possibly incorrectly) that these widgets are using PDF
>>> > features which are a bit out toward the edge of the PDF galaxy, but in
>>> > case
>>> > it is a "me" problem I come to the list, cap in hand.
>>> > Can anyone tell me how I can fix my example so that a selected radio
>>> > button prints out visibly selected?
>>> > [[
>>> > This PDF causes my "evince" program to dump core. Without the buttons
>>> > evince is somewhat happier, in that it doesn't dump core. I will wildly
>>> > guess that these problem are somehow related.
>>> > ]]
>>> > (In case you are wondering... I created a fourth button because I don't
>>> > want any visible button to be selected when the document is opened, and
>>> > other methods I tried failed in various ways, depending on the program
>>> > used
>>> > to view the PDF.)
>>> > Thanks.
>>> > Jim
>>> ___________________________________________________________________________________
>>> If your question is of interest to others as well, please add an entry to
>>> the Wiki!
>>> maillist :[email protected]
>>> /https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
>>> webpage :https://www.pragma-ade.nl /https://context.aanhet.net (mirror)
>>> archive :https://github.com/contextgarden/context
>>> wiki :https://wiki.contextgarden.net
>>> ___________________________________________________________________________________
>> ___________________________________________________________________________________
>> If your question is of interest to others as well, please add an entry to
>> the Wiki!
>> maillist :[email protected]
>> /https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
>> webpage :https://www.pragma-ade.nl /https://context.aanhet.net (mirror)
>> archive :https://github.com/contextgarden/context
>> wiki :https://wiki.contextgarden.net
>> ___________________________________________________________________________________
> \setupinteraction[state=start]
> \starttext
> \setupfield
> [radioSetup]
> [option=printable,
> width=1.2em,
> height=1.2em,
> frame=on]
> \definefield
> [choice]
> [radio]
> [radioSetup]
> [Aaa,Bbb,Ccc]
> [Aaa]
> \definesubfield[Aaa][][]
> \definesubfield[Bbb][][]
> \definesubfield[Ccc][][]
> Choose one:
> \blank
> Aaa \field[Aaa]\quad
> Bbb \field[Bbb]\quad
> Ccc \field[Ccc]
> \blank[2*big]
> Selected value should be: Aaa, Bbb, or Ccc.
> \stoptext
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : [email protected] /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
