Can I browse and change images at runtime for Image field?
Answer:The Image field does not currently support browsing and selecting an image. However, you can achieve this functionality by creating your own custom widget or by using JavaScript.
There are some Frequently Asked Questions (FAQ) about layout, scripting support, and scope of Mobile Forms in LiveCycle ES4.
Can I browse and change images at runtime for Image field?
Answer:The Image field does not currently support browsing and selecting an image. However, you can achieve this functionality by creating your own custom widget or by using JavaScript.
Why do barcodes and signature field in not appear in my form?
Answer: Barcodes and signatures fields are not relevant in HTML or mobile scenarios. These fields appear as a non-interactive area. However, LiveCycle Designer provides a new signature scribble field that can be used instead of signature field. One can also add a custom widget for barcodes and integrate it.
Is Rich Text supported for the XFA Text Field?
Answer: The XFA field, which allows rich content in Livecycle Designer, is not supported and is rendered as normal text without support for styling the text from the user interface. Also, XFA fields with comb property are displayed as a normal field, though there are still restrictions on number of allowed characters based on the value of comb digits.
Are there any limitations regarding using repeatable Subforms?
Answer: Repeatable Subforms with initial count of zero do not work. A workaround is to add a script on the formReady event that checks the instance count of that subform: If instance count is zero, add one instance and mark it hidden; else do nothing.
Are there any limitations regarding using hidden subforms?
Answer: A hidden subform with complex hierarchy that is split across pages causes layout issues. A workaround is to mark the subform initially visible and then hide it in an initialize script based on some logic or data.
Why some text are truncated or are displayed incorrectly in HTML5?
Answer: Where a Draw or Caption text element has not been given enough space to display content, the text appear truncated in mobile form rendition. This truncation is also visible in the Design view of LiveCycle Designer. Though this truncation can be handled in the PDFs, it cannot be handled in the Mobile Forms. To avoid the issue, provide enough space to Draw or Caption Text so that it does not truncate in the design mode of the LiveCycle Designer.
I am observing layout issues related to missing content or overlapping content. What is the reason?
Answer: If there is a Draw Text or a Draw Image element along with another overlapping element at the same position (say a Rectangle), the Draw Text content are not visible if it comes later in the document order (in LiveCycle Designer Hierarchy view). PDF supports transparent layering but HTML/browsers do not support transparent layering.
Why are some fonts displayed in the HTML form different from the ones used while designing the form?
Answer:Mobile Forms do not embed fonts (in contrast to PDF forms where fonts are embedded inside the form). For the HTML version of form to render as expected, ensure that the fonts specified in the XDP are available on the server and on the client machine. If the required fonts are not available on server, then fall-back fonts are used. Moreover, if the required fonts are not available on client, then default fonts of the browser are used to render the text.
Are vAlign and hAlign attributes supported in HTML forms?
Yes, the vAlign and hAlign attributes are supported. The vAlign attribute is not supported in Internet Explorer and in multiline field.
Do Mobile Forms support Hebrew characters?
Mobile Forms support Hebrew characters in all the browsers except Microsoft Internet Explorer.
Do Mobile Forms have any limitations on numeric field?
Answer: Yes, Mobile Forms have a few limitations. If the number of digits are more than the count specified in the picture clause, then the numbers are not localized and are displayed in English locale.
Why HTML forms are larger in size than PDF forms?
A lot of intermediate data structures and objects such as form dom, data dom, and layout dom are required to render an XDP to an HTML form.
For PDF Forms, Adobe Acrobat has a built-in XTG engine to create intermediate data structures, and objects. Acrobat also takes care of layout and scripts.
For Mobile Forms, browsers do not have a built-in XTG engine to create intermediate data structures, and objects from raw XDP bytes. So, for Mobile Forms, intermediate structures are generated on the server and sent to the client. At client, javascript based script and layout engine use these intermediate structures.
The size of the intermediate structure depends on the size of the original XDP and the data merged with the XDP.
Are there any limitations regarding using tables in my xdp?
Answer: Complex Tables cause issues in rendering.
Are there any limitations in JavaScript implementation for HTML Forms?
Answer:
Are there any limitations in using formCalc?
Answer: Only a subset of the formCalc scripts is currently implemented. For detailed information, see Scripting Support.
Is there any recommended naming convention and are there any reserved keywords to avoid?
Do HTML5 forms support Tab order?
Answer: HTML5 forms support geographical tab order sequence. The fields/objects are read in left-to-right and top-to-bottom sequence. The custom tab order sequence is not supported.
Are there any reserved keywords in Mobile Forms?
Answer: All Mobile Forms APIs are reserved keywords. For custom APIs/functions, use a name that is not identical to Mobile Forms APIs. Apart from reserved keywords, if you use object names that begin with an underscore (_), it is recommended to add a unique prefix after the underscore. Adding a prefix helps avoid any possible conflict with Mobile Forms internal APIs. For example, _fpField1
What are the design consideration to keep in mind while designing an XDP?
Answer: While designing an XDP, ensure that the fields of a master page are not overlapped with the content area.