Re: widget woes (input fields)

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.

Interestingly, ordinary checkboxes do not seem to suffer from the same 
problem.

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.

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 attaching the MWE used for testing.

JP



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
> ___________________________________________________________________________________

___________________________________________________________________________________
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