Problems with Displaying Forms on Mobile Phones

[Chinook]

I wanted to bring to your attention an issue we are experiencing with the display of the form on mobile devices. Currently, the correct visual representation of the form with variable fields is not rendering properly. The content of the text is not entirely relevant to this issue, so I have not made a translation of that portion.

error phone view.pdf

As illustrated in the attached images, each option is supposed to serve a different purpose. However, one option returns no display, while options two and three provide different text variations.

Correct view

noone.jpg

1one.jpg

2one.jpg

3one.jpg

Unfortunately, this functionality only works on PC; on mobile devices, it fails entirely—even within Acrobat Reader App.

Screenshot_20250424-141108_Adobe Acrobat.jpg

Screenshot_20250424-141228_Adobe Acrobat.jpg

Screenshot_20250424-141254_Adobe Acrobat.jpg

We have also tested additional options using the Samsung PDF viewer and Microsoft 365, but the problem persists across these platforms.

Screenshot_20250424-141458_Samsung Notes.jpg

Screenshot_20250424-141623_M365 Copilot.jpg

Currently, all fields are visible even though they should not be. Additionally, none of the text that is supposed to be displayed is showing as expected. This problem affects the functionality of the form.

Is there any possibility to address or optimize this issue for mobile phones? Alternatively, we will have to remove all the alternative text options due to compatibility issues with mobile devices.

Thank you for your attention to this matter. I look forward to your guidance on how we can resolve this issue.

Best regards,
Tomas

[Daniel - PDF-XChange]

Hello, Chinook

I am afraid that it is not possible for anything on our end to affect this. What you are seeing there is a display/rendering issue in the mobile apps that you are using. This document is properly formed, but unfortunately the vast majority of the mobile market does not work well with "dynamic" PDF form fields, and in most cases, does not fully understand the PDF specification. In particular, JavaScript-based actions, like those used in this file to show/hide the content, are notably problematic for such devices.

We strictly adhere to the PDF Specification during creation processes, so any file we create should inherently be as "compatible" as possible with any application that understands the PDF specification. Due to the prior mention of Mobile apps often not being fully Specification aware/compliant however... There is a small caveat here. If you wish to create a form which is as "compatible" with mobile devices as possible, avoid using most dynamic content, and stick almost exclusively to plain "text" boxes and "checkmarks". Avoid buttons, image fields, date fields, and any other "script-based" form items, to ensure that the simplistic actions mobile devices can perform have the least chance of failure. I am also unsure how well these apps can handle embedded fonts, so it is likely best to avoid embedding, and only use those that are considered to be "universal" (EG: Arial).

Since my last bout of market research (about a year ago, so things may have changed), the Adobe and Google PDF viewers were without a doubt the best options on the mobile market in this area. I believe both can now support dynamic Date fields even on mobile, but many other functions, such as visibility toggles, are still quite limited. Sadly, the variability (or limitations) from Operating systems and available resources (such as fonts and scripted actions) in a mobile environment makes developing capable PDF software, much more complex, and that is likely the root of these issues.

In this case, the best I can suggest is that, when you encounter issues like this, you reach out to the developers of the mobile app in question, and inform them of the issue. Hopefully they can try to improve their software to account for such cases.

Kind regards,

[Chinook]

Hello, Daniel

Thank you for clarifying the issue. I found it particularly strange that the fields display, but not the text, which is shown by the same script. If it had shown the text, I suppose I would have realized that this is the problem you are describing.

I have one idea for further development related to this - mobile device conversion. Let's face it, at least 50-75% of users typically view content on mobile devices. It would be great if the program included a feature for optimizing content (create new pdf) specifically for mobile devices - especially increasing text size/reducing margins. Always in connection with the original document. Unfortunately, I see a problem with forms in this regard, as form fields are separated from text fields and cannot be merged temporary into one object.

By the way, this would also be a very useful feature for working with pdf (or maybe I just haven’t discovered how to do it) - if I need to move text along with the form field. No problem - I can lock both into one object and move them at once, without having to manually center the field to the moved text afterward. This would be great feature.

Kind regards,

[Daniel - PDF-XChange]

Hello, Chinook

While the mobile market is indeed a big one, it is also a problematic one. Development for mobile devices is in itself highly restrictive on what can be offered, and making such concessions often results in reduced, or even outright incorrect handling of certain situations, as you have already experienced. There may be some ways to approach this in the future, but for now I cannot make any promises.

As for the latter request - From a technical standpoint, Form fields are a special subset of comment which have an adjacent relationship, but must be manipulated in a distinct way from them, preventing such group actions in the vast majority of cases.
There may be some special cases where reduced functionality could allow for it, but it would be a large undertaking and require a special tool just for that type of selection.

Kind regards,