Posts tagged "LiveCycle"

Decoding Mobile Form Html

Mobile Form generates html snippet from XDP template designed from LiveCycle Designer. In this post, we will decode the internal structure of the generated html snippet. Once you are familiar with the html structure, you can customize it at will.

Generally, Mobile Form generates an html <div> element for every object of XFA form maintaining the same hierarchical structure. Here is the html snippet source of the xfa form and the red lines shows the 1-1 mapping between xfa objects and html.


As mentioned earlier, for each xfa object, Mobile Form will have a corresponding div. Every div has, in general, 4 attributes:

  1. class: This is the attribute that should be used for customization. Mobile Form generates many different class selectors based on the various attributes of XFA object. One can use these class selectors to specify styles on the objects.
  2. id: This is for internal usage. There is no guarantee for getting same id all the time. Anybody shouldn’t use it for customization.
  3. style: This is again for internal usage. XFA form specific layout styles are applied on the element using this attribute.
  4. data-xfamodel: This is again for internal usage. Mobile Form keeps xfa form specific data in this data attribute. One should not temper with this to ensure smooth processing.

All set for customizing the individual html elements of Mobile Form, well, you need to know what all class selectors are applied on each div element. Mobile Form first adds a class for type of objects like subform, field, draw, area etc, then subtype of object like if it a field then what type of field: textfield, choicelist etc then the name of the object. You will find these 3 class selectors on each and every html div element corresponding to XFA objects. Here is the complete list:

XFA Object Class Selectors in Html div
Button field, buttonfield
Check Box field, checkboxfield
Circle draw, arc
Content Area contentarea
Date Field field, datefield
Date/Time Field field, datetimefield
Decimal Field field, numericfield
Drop-down List field, choicelistfield
Email Submit Button field, buttonfield
Image Field field, imagefield
HTTP Submit Button field, buttonfield
Image draw, image
Line draw, line
List Box field, choicelistfield
Numeric Field field, numericfield
Password Field field, passwordfield
Print Button field, buttonfield
Radio Button field, radiofield
Rectangle draw, rectangle
Reset Button field, buttonfield
Signature Field field, signaturefield
Subform subform
Table subform
Text Field field, textfield
Text draw, text
Time Field field, timefield

Besides the above class selectors, Mobile Form adds the name of the object as a class selector also. This is very useful if you want to apply some customizations to a particular field or draw element.

I will now backup a bit and describe how Mobile Form generates an html form from an XFA Form.
The initial html snippet generated by Mobile Form looks like the following with all the jsp variables <%=@@variables@@%> expanded into encoded html strings, as soon as you open any form in the browser:


Here formAction is the submitUrl specified in the request parameter. For detail on the request parameters refer Mobile Form. The <div> at line 2 contains all the data required to show a form. The _initializeXfaLoading() method of xfa runtime javascript generates the actual form while loading which will look like following:

Now let’s see how Mobile Form represents individual XFA Objects into Html objects.
For draw elements, Mobile Form uses SVG.
The text objects are represented using SVG Text. We don’t use html text because the layout generated by the html text doesn’t really match up to the text layout by XFA. SVG Text gives more control to the author by not doing auto layout. The “text” element of SVG has textLength attribute that gives finer control over the length of the text object. SVG is the primary reason why Mobile Form looks closer to PDF Form. Similarly line, arc and rectancle are represented by SVG only. Only The image object is represented using html5 <img>.

XFA Field object is wrapped in one html <div> that contains two different <div>, one each for caption and widget, something like the following:

Field caption is represented in SVG just like the draw text object whereas the field widget, the interactive area or the area where user can click and fill the data, is represented using html5 <input>. If caption is not present on the field, Mobile Form not only omits the caption div but also merge widget div and field div. Every div has a performance cost while loading the page or interacting with it. So in order to optimize the user experience, we merge div elements. For Date Field and List Box, Mobile Form uses javascript widgets to match up to widgets in PDF Form.

Mobile Form data submission

Mobile Form is a form after all, a way to capture user data at the end of the day. Once you got the data from users, you want to feed that data for further business processing.  If you see my first post on mobile forms you would notice there is a API parameter submitUrl that can be of help here. You can configure your Mobile Form to post data in xml format to your service on submission of the forms. Since you can invoke any LiveCycle process or service RESTfully, you can technically trigger a process on form submission. In this post, I’ll describe how to trigger a process on form submission in detail. You can follow the same approach to POST the form data to any service.

All LiveCycle processes can be configured to be invoked over REST endpoint. You can create a process in your application and configure it for default start point. You can create a process to have input and output variable.

Mobile Form posts data to the specified submitUrl via data request parameter. If you don’t specify custom any “submitUrl”, the default submission servlet will show you the data in your browser. You can easily customize the default submission servlet and send data for further processing.

You can download custom submission servlet package from here and install it via package manager by browsing http://<server>:<port>/lc/crx/packmgr. For details see package manager help.

Now download the FormSubmission LiveCycle process and import it following the instructions. You can create your own process as well. The important part is to get the REST url of the process. The rest url of the process turns out to be http://localhost:8080/rest/services/<ApplicationName>/<ProcessName>:1.0 as shown in the screenshot of workbench.



If you hit the REST url in the browser, it will ask for credentials of a user that can run this service or process. You can also disable the authentication required for running this process, for details look for adobe help.

http://localhost:8080/lc/content/xfaforms/profiles/default.html with the following parameters:

  • contentRoot repository:///Applications/FormSubmission/1.0
  • template=SimpleForm.xdp
  • submitUrl=Encode the URL and then pass(http://localhost:8080/lc/content/xfaforms/submission/default.lcprocess?postProcess=http://localhost:8080/rest/services/FormSubmission/archiveForm:1.0)


As you can see, the submitUrl is pointing to the custom servlet with a request parameter “postProcess” where custom servlet further posts data. The “postProcess” service could be any other servlet but in this case it is the REST url of the LiveCycle process.

The attached form in the Form Submission collateral has just two fields and the “archiveProcess” creates a flat pdf  from the submitted data. You can test the form by rendering it and when you submit the form, it triggers the LiveCycle process and generate pdf out of it and serve it in the browser.




Mobile Forms: LiveCycle Designer way

You want to quickly test your designed form on how it would look like as Mobile Form, you can do it right from the livecycle designer without any other application. You first need to point your designer to use an LiveCycle ES4 server. You can configure it in LiveCycle Designer menu Tools->Options->Server Options like the following:




Now open an existing form or a new form in the LC designer, you would notice a tab HTML Preview near by Design View, Master Pages and Preview PDF. If you cannot see that tab don’t worry just locate HTML Preview in the view menu option and enable it. When you click on the HTML Preview tab, you would see the html preview of the currently opened form in the designer.




See how easy it is to preview html forms while designing it. This will speed up the development of the form as one can preview both PDF as well as HTML right from the designer itself. In the next post I’ll share how one can test templates outside of the designer and in the browser.

Accessible Mobile form

An accessible form is one that a wide range of people can use, including those who may have disabilities that affect how they are able to interact with the form on the computer screen. For example, the form user may have a visual impairment or reduced mobility.

Mobile form uses ARIA html5 accessibility standard to support a number of features and capabilities that enhance the usability of forms for users with a range of disabilities, and assist form authors and create forms that are more accessible to people with disabilities.

When you design forms for a wide audience, you should consider that some users may have disabilities that affect how they interact with the form. Some users may have vision impairment, reduced mobility, or other disabilities. To accommodate the needs of all users, you may find it worthwhile to include certain practical design features in your forms and to test forms using various assistive technologies.

Setting a meaningful tabbing order is very important when designing forms that are accessible to users with vision impairment or users with disabilities. These users typically do not use a mouse to navigate through a form, so they depend on the keyboard. A logical tabbing order sequence ensures that they have full access to all the fields on the form and that they can navigate the form in a way that is sensible and efficient. Screen readers and other assistive technology also make use of the tabbing order.

In order to access spoken information about a form, users with vision impairment need to use a screen reader. Screen readers speak information about where the cursor is located on the form. As the form author, you must specify the text for the screen reader to read.

To provide an accessible form, you need to understand how screen readers work. You also need to know how to use the Designer Accessibility palette to specify information that the screen reader will speak for the objects on forms. Keep in mind these considerations related to implementing accessible forms that can support screen readers:

  • Establish a logical tabbing order that includes all fields and buttons. Setting the tabbing order is important because screen reader tags are ordered top-to-bottom, left-to-right. The screen reader will generally read through an entire page, including any boilerplate objects. When the user begins to tab through the form, the screen reader reads text for each field as it becomes active.
  • Announce the names of buttons and fields, as well as their purpose.
  • Users cannot tab into protected fields. Calculation fields, such as a field that totals values entered in other fields, are an example of a protected field. For the screen reader to read the value of a protected field, you can place an empty Read Only field either on top of or next to the protected field to speak the value of the protected field.

LiveCycle ES Designer includes a number of options that support screen readers. For each object in a form, you can specify one of several settings for the screen reader text:

  • Custom screen reader text, which you set in the Accessibility palette.
  • Tooltips for objects on the finished form, which you set in the Accessibility palette.
  • Captions for fields on the form.
  • Names of objects, as specified in the Name option of the Binding tab.

Only one setting is spoken for a single object. The screen reader searches for the presence of these settings to determine what is spoken. The default search order is Custom Text, Tooltip, Caption, and Name. When the screen reader finds one of these options, it speaks that text. You can override this default order using the Screen Reader Precedence option in the Accessibility palette.

Scribble your forms

With new Mobile Forms, it is much easier to customize the forms than ever. In this post, I will cover one such improvisation that Mobile Form provides out of the box. Mobile Form extends image field to provide a scribble control on the form. The users can scribble any useful drawing, for example their signatures to the form. This control comes in the livecycle ES4 designer out of the box. Due to its close proximity with paper signature, we call it signature scribble. So here is how you design a form with scribble.

Open any existing form or a new form in LiveCycle ES4 Designer. Drop in signature  scribble object from the Object Library pane as shown below:



Once you open the form in browser you will see the following UI experience. You can scribble anything using the brush and save it. This control is only available for mobile forms. In pdf world this will be treated like an image and you don’t see any interactivity with that image.


Mobile forms Vs Pdf forms

Mobile forms component enables XFA forms on mobile devices. The same XFA form that can be used for generating pdf, can be used to generate html form as well. The html version should behave almost exactly same as the pdf version. XFA has a very rich support for scripting. It supports tons of APIs and almost all the properties are exposed via scripting interface. But as the famous 80-20 rule suggests our customers use only 20 % of that capability. The difficult part was to find those script constructs that are used in real world cases and prioritize them higher than the rest of the script constructs. We have run through the large collection of customer XDPs we have and generated the list of javascript constructs that people use. Interestingly, we found that usage to be less than 20%. Out of 2600 javascript object properties and APIs, forms were using around 200 constructs at least once. So we decided to prioritize based on it.  Mobile Form is covering that gap fast but there would be certain things that would never make sense in html or mobile world.

Here is screenshot of both pdf as well as html form for comparison.




html_formThen there are things that matters in pdf world doesn’t have same importance in html/mobile world, e.x. barcodes. Barcodes are more relevant in printed documents so we decided to do away with this barcode object purely from UI level. We still keep it at model level so one can always generate pdf with barcode using the data exported from the html form. If required, one can always insert custom widgets to show barcodes on html form. That is the beauty of Mobile Form architecture. It is way more open than the pdf form where all the widgets are locked down. In Mobile Forms world, one can customize the widgets to enhance the user experience on Mobile devices. For example, one can replace the xfa numeric field with the slider object to capture number information from users.

Signature field is another component that can be interestingly done using the html world solutions like e-sign. So we decided to de-prioritize it for Mobile Forms. On the other hand, we provide a scribble object, using that one can scribble his signature on the form and it will be saved as an image on the form. More detail on the scribble form can be found here.

As I mentioned, Mobile Form will look like almost same as Pdf form. Time has come to explain the almost part here. Mobile Form, because of its html nature has lot of advantages, for example easier to customize, faster opening time, availability on mobile etc. But it has its own set of inherent issues also like support for very thin lines thinner than 1 px.

We use data uri scheme to show images in the Mobile Form. This is supported by all the modern versions of the browsers but you cannot help but notice the differences in the range of image formats that these browsers support. So one should test the images across all the browser matrix before deploying the forms.

In mobile form, pagination, the ability to generate pages due to content changes like adding enough text in the text box to go beyond page boundaries, doesn’t matter. But keeping all the content cluttered would not look nice either. Mobile Form, that is why, chooses a hybrid approach where it generates panels, a box to give feel of pages, as many as there is in the template but it doesn’t increase or reduce panels by data content merged or by user content.


Forms Management

This is second post in my previous series of LiveCycle Mobile Forms. In this post, I will introduce utility tool called Forms Management that eases out forms deployment on live production systems.

The Forms Management streamlines the process of updating, managing, and retiring thousands of forms and the business users can manage forms without any help from IT support.

One can access Forms Management console through http://<server>:<port>/lc/fm. Here is how it looks like once you log in using super admin user.



There is search control where one can search through the forms. Forms Management UI shows all  LiveCycle applications that contains forms. You can go and select one of the applications and browse into the forms. You can select the forms and preview it as pdf or html5. Here is how preview screen looks like:



You can select a form and edit metadata corresponding to it and the metadata is searchable too.

LiveCycle Mobile Forms

One of the many new offerings in LiveCycle ES4 is Mobile Forms that is ability to display and fill forms on mobile devices like iPad and other tablets. Mobile forms uses the already stable and widespread html5 as its rendering format so practically, any device that supports html5 can show LiveCycle forms. With the explosion of mobile devices, our existing customers were looking for this component to increase their reach and not only that, it would also enable many new use cases. Mobile Forms plays key role in customer’s workflow and enabling that workflow step on mobile device will further reduce the time taken to complete the process.

Mobile Forms generates html5 document for XFA forms. The API is RESTful, another change from the Document based LiveCycle service APIs as html is more suited for http requests. Html fragment for XFA form can be embedded into any html document.

“Web” and “online” are two closely associated terms, downright synonymous to many people. But with the advent of html5, now people are developing offline web apps. Mobile Forms, being an html5 document, can also be used to build offline forms.  So one can open the form even if she is not connected to company intranet or for that matter internet. Mobile Forms closely follow the html5 offline W3C spec for building offline-able forms. I’ll discuss this feature in detail in some other post. Let’s focus on html5 form render first.

As I mentioned Mobile Forms is a RESTful application and its render API has the following commonly used parameters to specify form and data:

Parameters Description
template This parameter takes the file name of the template.
contentRoot This parameter is for specifying the path where template and associated resources resides.
dataRef This parameter takes absolute path of the data file to be merged with the template. Please remember it takes absolute value of the data file path.
data This parameter takes UTF-8 encoded data bytes to be merged with the template.
submitUrl The url where the form data will be posted to.
debugDir Directory location on server machine where the debug intermediate files will be dumped. Do not use this parameter in production as it will slow down the rendering considerably. This parameter is for Adobe internal usage and can be changed in the future.
templateBytes This parameter takes UTF-8 encoded template bytes to be rendered. This is again Adobe internal API and can be changed in future.

As you can see, Forms Mobile render API is fairly simple and can be easily used. Out of the box, the render API is exposed on both GET and POST. The sample uri looks like the following:


Hit the above URL in browser and see your XFA forms being rendered as html5 document. XFA forms can also have webservices or scripts that are to be run on server side. In that case, the rendered html doc contacts http://<lcserver>:<port>/lc/content/xfaforms/submission/default.html url so make sure you don’t block this url while hardening the system in order to smooth functioning of form.


In the next post I’ll cover how to quickly test the forms.



Mobile Form Configuration

Caching in Mobile Forms or any solution for that matter, plays key role in the performance. On the other hand, cache takes finite space to store intermediate artifacts that means you trade memory for better performance. In Mobile Form solution, we have exposed different strategies of caching to fine tune this trade off. I’ll first describe all the levels and what do they mean and then how to change the levels.

Mobile Form has 3 different strategy of caching that can be controlled using the configuration.

Cache Strategy Description
None This cache strategy enforces the solution no to cache any artifact. This will, in practice, slow performance and high memory availability due to absense of cache.
Conservative This cache strategy dictates to cache only those intermediate artifacts that are generated before the render of the form like template containing inlined fragments and images.
Aggressive This cache strategy enforces the solution to cache almost everything that can be cached. This includes rendered html content besides all the artifacts from Conservative level. This should result in best performance but it will also consume more memory for storing all the cached artifacts.

Aggressive caching strategy means you will get O(1) or constant time performance in rendering a form as rendered content of the form is cached.

The following section describes how to change the caching strategy based on you requirement:

  1. Go to  http://[server]:[port]/lc/system/console/configMgr and look for “Forms Configuration” and click on it. You see a dialog like following:
  2. You can select Cache strategy using the drop down.




Besides Cache strategy, one can also configure total in memory cache size and the upper bound on the size of the individual artifacts to be cached. HTML Forms, as of now, only do in-memory caching using LRU strategy.

If you select ‘None’ cache strategy, the cache gets cleaned up.

RFID Label printing

RFID: Radio frequency identification A method of identifying unique items using radio waves. Typically, a reader communicates with a tag, which holds digital information in a microchip. But there are chipless forms of RFID tags that use material to reflect back a portion of the radio waves beamed at them.

Form Authoring

XFA has the capability to handle barcodes since beginning. In Adobe LiveCycle ES1.0, we introduced the support for elementary RFIDs also. It is  handle like any other barcode and named it rfid. The form author can put an rfid object on the label while designing label using Adobe LiveCycle Designer.

RFID set up in Adobe LiveCycle Output

To enable the rfid capability in Adobe LiveCycle Output service, first, the user needs to do rfid set-up based on the target rfid printer. The user has to configure the RFID parameters in the XDC file using Adobe LiveCycle XDC Editor, based on his rfid printer configuration before printing his first rfid label.
There are four device options in the XDC that one needs to configure.


It controls the number of times the printer attempts to write to a particular block of a single RFID tag. The accepted values for this option is between 0 to 10.
If the user doesn’t specify in its XDC, the printer will take the default value ‘0’.


The number of labels that will be attempted in case of encode/write failure. This number is different from the rfidBlockRetries. The accepted values for this option is between 0 to 10.
If the user doesn’t specify in its XDC, the printer will take the default value ‘3’.


It controls the encoding type of the data in the RFID label. The RFID readers should have same tag type as the rfid printer has. The accepted values for this option varies printer to printer. Consult your printer manual for this. Generally this option takes values between 0 to 5.

value tag type
0 None
1 EPC Class 0
2 EPC Class 0 Plus
3 EPC Class 1 64-bit
4 EPC Class 1 96-bit
5 ISO 18000-06B

These tag types also has some frequency standards. In some countries, some of the frequencies are restricted and in that case the rfid printer might not support those corresponding tag types. In that case the printer will use the default tag type. There are number of other EPC and ISO standards.


This is the distance of the microchip on the label from the top. The user needs to pass this value in dots. The accepted values are between 0 to length of the label.
If the microchip is located at the beginning of the label, the user needs to simply set this option to 0.


This is the setting which will be specified based on the fact whether the data used is HEX or ASCII.


Here you go. Once the above set-up is taken care of, you can generate the labels using the generatePrintedOutput API of AdobeOutputService. You can upload the edited XDC file in the Adobe LiveCycle Repository and pass its uri as XDC URI in the API.


A quick disclaimer here that RFID capability is supported only for Zebra labels (zpl) and not in PS/PCL or pdf documents generated by Adobe LiveCycle Output.