You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pdf V_in_parent.pdf has been created in Acrobat and contains a text field (25R) where the V entry is in its parent.
I opened it in Firefox, changed the field value, saved it and I got the second attached pdf.
In V_in_Field.pdf, the V entry is in the field itself and should overwrite the value from its parent.
If I open the saved pdf in Acrobat and I click on the first field then the value is the V one from the parent (the one displayed when the field is unfocused comes from the appearance).
According to the specs, the Ventry is inheritable which means (according to the specs again):
Many field attributes are inheritable, meaning that if they are not explicitly specified for a given field, their values are taken
from those of its parent in the field hierarchy.
So normally, the V entry should be taken from the field and not from its parent... it's what we do in pdf.js, but unfortunately, Acrobat and Chrome take it from its parent.
I don't know if it's a "bug" only with the V entry or if we should reconsider the definition of "inheritable" in general.
When saving, we must write the V entry at the right place.
The text was updated successfully, but these errors were encountered:
In fact, the pdf has a field (10R) which has a single kid which is a widget (25R).
The widget is used to give an appearance to the field. So the value of the field (V) is in the field (10R) and not in its kid.
The specs explain that:
Each field in a document’s interactive form shall be defined by a field dictionary (see 12.7.3, “Field
Dictionaries”). For purposes of definition and naming, the fields can be organized hierarchically and can inherit
attributes from their ancestors in the field hierarchy. A field’s children in the hierarchy may also include widget
annotations (see 12.5.6.19, “Widget Annotations”) that define its appearance on the page. A field that has
children that are fields is called a non-terminal field. A field that does not have children that are fields is called a
terminal field.
A terminal field may have children that are widget annotations (see 12.5.6.19, “Widget Annotations“) that define
its appearance on the page. As a convenience, when a field has only a single associated widget annotation, the
contents of the field dictionary and the annotation dictionary (12.5.2, “Annotation Dictionaries”) may be merged
into a single dictionary containing entries that pertain to both a field and an annotation. (This presents no
ambiguity, since the contents of the two kinds of dictionaries do not conflict.) If such an object defines an
appearance stream, the appearance shall be consistent with the object’s current value as a field
So when a widget has a parent, we must take the V in the parent and when we save it we save the V in the parent.
Attach (recommended) or Link to PDF file here:
V_in_parent.pdf
V_in_Field.pdf
Configuration:
The pdf
V_in_parent.pdf
has been created in Acrobat and contains a text field (25R) where theV
entry is in its parent.I opened it in Firefox, changed the field value, saved it and I got the second attached pdf.
In
V_in_Field.pdf
, theV
entry is in the field itself and should overwrite the value from its parent.If I open the saved pdf in Acrobat and I click on the first field then the value is the
V
one from the parent (the one displayed when the field is unfocused comes from the appearance).According to the specs, the
V
entry is inheritable which means (according to the specs again):So normally, the
V
entry should be taken from the field and not from its parent... it's what we do in pdf.js, but unfortunately, Acrobat and Chrome take it from its parent.I don't know if it's a "bug" only with the
V
entry or if we should reconsider the definition of "inheritable" in general.When saving, we must write the
V
entry at the right place.The text was updated successfully, but these errors were encountered: