pdf-association
Forms.next requires that `V` & `DV` keys be allowed on push buttons
This will bring it into alignment with HTML and provides a way for the form to include information about what button was chosen to perform submission.
"Table 226 - Entries common to all field dictionaries" already defines both V and DV so they can occur for push buttons.
So you must be referring to the statement in 12.7.5.2.2: "Because this type of retains no permanent value, it shall not use the V and DV entries in the field dictionary (see "Table 226 — Entries common to all field dictionaries")." which I interpret as a processor requirement because of the verb "use", and not a file format requirement.
So I don't see an issue regarding the presence of V and DV entries for push buttons - but they don't have any meaning. Did you want to add a meaning???
For background: HTML a button value is included in a submit operation for the button that was clicked to initiate the submit.
For our purposes, we should allow push buttons to store a value and a default value.
Recommend removing the text from 12.7.5.2.2:
Because this type of retains no permanent value, it shall not use the V and DV entries in the field dictionary (see "Table 226 — Entries common to all field dictionaries").
@JohnBrinkman I think you can make a case for weakening that 'shall' to a 'should'. Though I'm curious as to what the processor requirements might be for a Pushbutton field with an associated value.
There's also a key word (button) missing from that sentence that is in my copy of PDF32000_2008.pdf but not in my ISO_32000-2-2020_sponsored.pdf.
@datalogics-pgallot
I'm curious as to what the processor requirements might be for a Pushbutton field with an associated value.
The requirement is compatibility with HTML forms. HTML buttons may be assigned a value. And if that button is clicked to initiate a submit form action, then the value of the clicked button is included with the submitted form data (all other button values are omitted by default).
We could make a case for allowing buttons to have a value at runtime, but not serializing the value. But that would be inconsistent with any other field behavior.
Current wording with the verb "use" implies that this is a processor requirement (note: other places in the spec would reword this to use the trigger verb "ignore"), and not a file format requirement (that would need to use wording such as "present"). Table 226 already allows V and DV in the file format so removing this processor requirement from 12.7.5.2.2 doesn't alter file validity - it only softens to allow s/w to now do something based on V or DV values.