Files
pdfcraft/parity
mtlcl410andClaude Opus 5.5 f1c47db032 M6: a radio option whose export value is a number selects its own button (ISO 32000-2 Table 230)
A radio group with one /Opt export value per button and on states named
by position (/0, /1, ...; ISO 32000-2 Table 230) took the export value
"1" as the state /1, so it turned on the second button. Static XFA forms
build every exclusion group this way, with items 1, 2, 3. Asking for
option 1 selected option 2, 2 selected 3, and only the last option came
out right. Clicks wrote the button's position (0, 1) into the XFA data
instead of its item (1, 2), and XFA 3.3 ch. 4 and 17 say that data holds
the member's "on" item.

- Field::state_for_export resolves an export value: the per-widget /Opt
  first, then the on-state names. state_for, which callers holding a
  state (a click) use, is unchanged.
- form_fill resolves a radio option (the export value form_fields lists)
  with it, and so does opening a static XFA form for the data's item. The
  pre-strip comparison against the data compares export values.
- radio_dataset_value writes the selected button's /PCOn, else its /Opt
  entry, else its state name.

On 24 public XFA forms (benefit, disability, pension and visa
applications) a fill test flipped 329 radio groups on main and none with
this change.

Tests (each fails with the fix reverted): a forms unit test, an
automation form_fill test on a pure AcroForm group, and an engine test on
a synthetic static XFA exclusion group (open from data, click, save and
reopen).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBVyQEwtmEw3mS1MoAiwrK
2026-10-31 14:01:27 +08:00
..