Field data not replaced if ReadOnly flag and field has apref tag

WebViewer Version: 8.6.1

Do you have an issue with a specific file(s)? Many of our PDFs
Can you reproduce using one of our samples or online demos? No
Are you using the WebViewer server? No
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? No
Is your issue related to annotations? No

Please give a brief summary of your issue:
When XFDF is supplied where a ffield has the ReadOnly flag specified, and the corresponding widget contains an apref tag, the field data (value) is not replaced in the displayed PDF.

Please describe your issue and provide steps to reproduce it:
The PDF contains a text field with a default value. The corresponding ffield has the flags=“ReadOnly” attribute. The corresponding widget contains an apref tag. When the PDF is loaded, if the field value in the XFDF is different, it is NOT shown on the PDF display – the original PDF’s field contents are shown. It appears that either (a) removing the flags=“ReadOnly” attribute from the ffield; or (b) removing the apref tag from the widget results in the proper display: the field value from the XFDF is shown in the PDF.

Problem reproduced in Chrome and FireFox.

Please provide a link to a minimal sample where the issue is reproducible: N/A.

I’ve attached the XFDF which shows the problem, and screen shots of the original PDF, and the WebViewer display given the XFDF. In this sample, both ‘field1’, without the apref, and ‘field2’, without the ReadOnly flag, display the replacement value. But ‘employeeName’ field, with both ReadOnly and the apref, does not – it shows the original PDF’s value. (I was blocked from uploading the PDF itself or a zip of it.)

fieldNotUpdated-PDF


fieldNotUpdated-XFDF.txt (1.4 KB)

Thanks!

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:

Guides:APIs:Forums:

Hello @Dwight

The appearance takes precedence but currently, this is only implemented for read-only text fields which is why you don’t see the appearance when you remove read-only. If you want to see the underlying field value you can remove the appearance from the XFDF.

Hi @dfelix ,
Hmm. This used to work (way back in v4, which we were running until trying to upgrade now to v8). I don’t know what the apref (appearance) tag does. The field displays the same with or without it, except that the XFDF merge ignores the field value supplied. Why should the existence of apref tag cause that to happen?

We have a few hundred documents, and having to go through all the XFDFs and eliminate the apref tags will be a major undertaking.

Any way around that would really be appreciated!
thanks.

Hello @Dwight

Sorry for not being so clear before: apref means that the annotation has an appearance, which will make webviewer (and other viewers too) disregard the drawing method and show just the appearance.

This is the correct behavior, actually. I’m not 100% sure of this, but it might be the case that WebViewer v4 did not handle this correctly.

One workaround is to set these widgets to not be read-only or, depending on how you import the XFDF, to parse the XFDF and remove those apref tags.

Hi @dfelix ,
Sorry, I just don’t understand the logic here. If the XFDF file contains a

<field name=…><value>some new text</value></field>

entry, why would that value get ignored? And even stranger, why would it get ignored in only the case where there’s both a ReadOnly attribute and apref tag?

We have to mark the fields ReadOnly in some cases as the documents become “locked” after they have been signed by someone.

Thanks.

Hello @Dwight

It gets ignored because that’s how appearances work: they override how the annotation is displayed.

From https://www.pdftron.com/documentation/web/guides/annotation/custom-appearances/ : “WebViewer supports adding a PDF object or page as an appearance to any annotation type. This allows an annotation to be displayed in a custom way which overrides the default rendering based on the annotation properties. This custom appearance is also compatible with the PDF specification so after downloading the file the annotation will appear identically in other PDF viewers.”

Hi @dfelix ,
Ok, thanks. I guess we’ll have to pull the apref tags.

Note that we currently use PDFTron 6.9.1 in other situations to merge these same XFDF files, and, at least in that version, the XFDF field text value is still used; the apref does NOT override it. Maybe it’s changed in more recent PDFTron versions.

Thanks again for putting up with all my questions. :slight_smile:

No worries @Dwight !