Is the `V` key required to be present on a Text Field?

[lrosenthol]

Table 226, Entries common to all field dictionaries, states that the V key is optional and comes in various data types.

In 12.7.5.3, Text Field, it states:

The field’s text shall be held in a text string (or, beginning with PDF 1.5, a stream) in the V (value) entry of the field dictionary.

In 12.7.6.3, Reset-form Action, it states:

Upon invocation of a reset-form action, an interactive PDF processor shall reset selected interactive form fields to their default values; that is, it shall set the value of the V entry in the field dictionary to that of the DV entry (see "Table 226 — Entries common to all field dictionaries"). If no default value is defined for a field, its V entry shall be removed.

So that implies that if you have a text field with no DV entry and a reset-form action is executed - the V entry will be removed. BUT w/o a V entry, is the field now out of compliance with 12.7.5.3, as I read it.

We should clear this up!

[petervwyatt]

See also Errata #323 and #387

[petervwyatt]

@romantoda

[mkl-public]

Well, it is possible to interpret 12.7.5.3 in a way that makes the conflict disappear: If one allows the notion of a field not yet containing text at all (either because it's created without text or because it's reset without a text default value), then 12.7.5.3 would not require a field in that state to have a V entry. 12.7.5.3 would then only require fields that explicitly have been filled in to have a V entry.

(BTW, this would give a null or missing V entry a different meaning than a () V value.)

But of course, having to resort to such interpretations to make a spec work, also indicates that it should be written more clearly... 😉

[romantoda]

Our implementation removes V and RV keys if DV is not present. So the fields without the V key should be allowed IMO

[petervwyatt]

@lrosenthol - could you please propose improved wording/clarifications for this and related errata?