XChange form field does not show content until clicked in

[Chinook]

error.pdf

Hi everyone,

I'm experiencing an issue that some of our clients have reported. We've sent out hundreds of forms, and some users notice that when they fill in a field and then click outside the form, the entered text disappears. Interestingly, this doesn't happen for all clients, nor does it occur with all fields within the same form, which is quite confusing.

To give an example: when I type or modify something in a particular field, the text only appears after I interact with the field (for example, by clicking or changing the content). Before that, it’s blank. This issue affects both text and number fields (like phone numbers), and it doesn’t seem to be related to the type of data entered — PDF tools still read the data correctly, so the problem isn’t with the data itself.

The latest issue is that if this problem occurs with a client and they save the form in a non-editable format, the data is permanently lost and we have no way to retrieve it afterward. This requires us to contact the client individually, which completely destroys their trust in our organization. If the fields were visible, we could simply re-write the data manually to database.

This inconsistency is causing a lot of confusion among our clients, and we haven't been able to find a solution so far. Any ideas or suggestions would be greatly appreciated. Thanks in advance!

[Daniel - PDF-XChange]

Hello, Chinook

Thank you for the sample file. Generally issues like this are caused by improper handling of the software which was used to FILL the fields, not on the creator's, or reviewer's part. One common example is Web browsers, which are being used for these purposes more and more as time goes one. While this is not inherently a bad thing, they are still learning how to handle PDF files, and currently... Most of them still do not properly understand the Specification, and may store this data improperly.

Sadly there is no clear indication of which app was used to fill a form, as none of that data is written to the document, all we can see here is the form data that exists improperly.

• Technically speaking, there are a multitude of "locations" in which form field data is stored. There is a separate dataset for the "appearance" (what you see when reading the document without selecting fields directly) and the "edited" data each. (In some sub-formats, like XFA, this gets even more convoluted)
  In modern practice, these values should almost always be updated at the same time, but some apps do not understand/respect this. We are following the spec by showing the relevant content data when it is intended to be shown according to the spec. As we need to expect that the file has been filled by a Specification compliant PDF software which understands these items... Sadly that expectation sometimes cases issues in cases like this, and trying to work around them might lead to damage in properly compliant files.
  
  As such, I can pass this up to the Dev team for review, but I cannot make any promises that we will be able to resolve the issue on this end.

It is worth noting that in cases where this has happened, clicking inside one of the files, which as you mentioned shows the data, put your into the editing mode I mentioned. Changing any amount of information here, including adding or removing invisible characters like a "space", will cause the Editor to re-write the field data values properly, so that the "appearance" matches the editing data. Like so:

PDFXEdit_MYoWpGJfyp.gif

• The best way to avoid these issues however, is to insist that anyone filling a PDF form, make use of a proper PDF software to do so. We do offer the Editor as a free download. With both filling and signing, available in the free version without any restrictions, so you can certainly recommend us. Clients who choose to do so can simply open your files, and use the hand tool to click inside any fields to begin filling. No need to activate other tools in any capacity.
  Beyond that, most of our competitors offer similar, so if they already have Foxit or Adobe installed (as examples) those both adhere to the PDF specification (better than a web browser), and should always fill the files properly. They can safely use any of these options and forms we created should work properly.
  
  The PDF Specification puts a great deal of emphasis on "mutual understanding" of its terms between applications. If two developers disagree on how to handle something, the Specification is the mediator for how the application must implement it. We strictly adhere to the Specification, to ensure that our documents and features are as universally compliant as possible.

Kind regards,

[Chinook]

Hello Daniel,

I was still browsing the website and an idea came to me.

Given that we use Arial font for document text according to company policy, which is not entirely part of the standard font pack in Xchange, wouldn't it help to set the font of the form fields, for example, to Times-Roman? This font might be more universal.

It's strange that the "faulty" fields are always the same, but not all fields in the form. The most peculiar behavior is with the phone number field, where it only displays the first digit and hides the rest, similar to other problematic fields. Unfortunately, due to data protection reasons and GDPR, I couldn't provide this field for review.

I was also advised to set the fields to a fixed size and not leave them on automatic, but I don't think that's the main issue, because it happens even with fields that have a fixed font size, and some fields with automatic font size don't have this problem.

I would like to give a complete client response, but unfortunately I had to do a lot of searching to send at least a sample, due to need respecting data privacy and GDPR.

Anyway, thank you for all your effort and communication.

Kind regards,

[Daniel - PDF-XChange]

Hello, Chinook

Regarding the fonts, it is sadly not that simple. The issue is not with the "font" itself, but the location in the PDF's internal data structure whereby it is stored, and what the Docuemnt claims should "mirror" that data. Beyond that, Arial is just as commonly accessible as Times New Roman is (both being default fonts installed on all modern Windows Operating Systems), but the selection of which to use would not have any impact on the issue. At most, if there was a font-related error, such as the document requesting one that was unavailable, the content displayed would use a substitute font that is locally available, most commonly, Arial.

Would it perhaps be possible to send us a blank copy of one of the forms, so we can try filling it with a few different applications here? If you prefer, you could send that copy to us via Email (Support@PDF-XChange.com), with a link to this forum thread.

Also, If your clients need a more "official" explanation, here is the terminology used by the Dev team to describe your sample file after their investigation.

This is caused by a third-party PDF editor—it did indeed write the information incorrectly. In the attached file’s structure there should be an appearance stream telling us what to render for the widget, but it’s incomplete. As a result, when the text inside the form field changes, the editor regenerates the appearance and you see the image even though the original stream was missing.

We are still looking into this case, to see what else we can do to alleviate the issue, but the Devs wanted me to confirm with you. Have you been able to cause this issue to occur specifically while filling a document using our software? (or is the issue exclusive to files filled in by those using other apps?)
If the issue can be caused in our Editor, could you confirm the version of the Editor that is running when that occurs, and if you are able to reproduce the issue in the latest release? (10.6.0.396)

Kind regards,

[Daniel - PDF-XChange]

Hello again,

I have just heard back from our Dev team Lead. It is now confirmed that there is nothing on our end we can do to cause or prevent this.. If this is happening, it is an effect from a third party application improperly filling the fields, and we are beholden to display as the Document requests. In some older builds (it seems you are still on V9, so that may be an issue) there may be cases where we are unable to "fix" these problems with follow-up edits, but the current release should be fully functional in this department.

As such, the only way to avoid this will be to advise those filling your forms that they need to do so with proper, up-to-date, tools. This is no error on your end or our own, but an issue the client themselves has pushed into the document with their chosen filling method. It is not your fault, and they should not lose trust in you because they submitted a faulty file.

Kind regards,

[Chinook]

error formular.pdf

Hello Daniel,

thank you for the information. Thank you for the update and for sharing the feedback from your Dev team Lead. I understand that this is not an error on your part or ours, but I still have a slight suspicion that there might be some issue on my side that could be contributing to the problem.

I apologize for the delay, but I am attaching the problematic older form—it's two months old (based on 12/2024 verzion). I have removed all the text that is not relevant to our matter. The fields marked in green are filled out correctly and display without any issues, always showing properly regardless of who fills them out, when they are filled, or which program is used. The fields outlined with a blue border are those where the text either does not display or only partially appears, such as the "Telefon" field, where only the first character is shown. I do not currently have access to the form from the investigator for the fields without a border and am unable to verify the output. Maybe this will help identify why the problem occurs only with some fields. I do not rule out that these fields might have been copied in some cases. In the latest, longer version, the problematic fields are clustered together, while the good fields are located between them (possibly created from scratch).

Kind regards,

[Daniel - PDF-XChange]

Hello, Chinook

I cannot seem to reproduce any issues when filling in the blue fields with our software (or for that matter, with any other applications on this end, including some web browsers). So It does not seem there is an issue specific to those particular fields. Are you personally able to reproduce the issue in the latest release (build 396) of our Editor? (or for that matter, using any other specific application, so I can test that and see if the same occurs here?)

I am afraid that there is nothing that can be done on our end unless we can find a case where the missing content is created/filled in by the current release of our software.
If it only appears when the fields have been filled by a third party application, that would be an error that need to be reported to the developers of that software, but we would like to know what applications are known to cause such errors, so we can investigate if any workarounds would be possible.

Kind regards,