Browsers or any screen presentation application for that matter translates all the measurements to pixels as screen can only understand pixels. So if you specify a text in html to be “10 pt (points)” it will be  calculated to pixels and then rendered on the screen. Point or any measurement unit conversion to Pixel is not exact science. It depends on various environment parameters like OS, screen resolution of the device etc. Yet, there is a very good approximation for that conversion and that is 1 inch = 72 points = 96 pixels.

If Mobile Form adheres to the standard approximation then one can see the same pixel perfect rendition of the form on PDF, Browser and Designer. We ran few heuristics across all the browsers and devices and it turns out that if we follow the standard scale we might loose on fidelity side due to differences in the imaging model of browsers and PDF.

For example, the default width of borders around the field or any line is “0.0069 inch”, if you design a form using LiveCycle Designer, which is co-incidentally also the most frequently used border thickness. If Mobile Form follow the standard scale that is “96 pixels” for “1 inch”, then this thickness would translate into “0.6624 pixels”. PDF imaging model is sophisticated enough to handle such subpixel sizes. The detail on how it does is beyond the scope of this document. But the browsers ignore anything less than a pixel. So following standard scale will result into no boders or lines in most of the forms.

While conceptualizing the Mobile Form, the main idea was to enable form filling on the browsers rather than matching the pixel perfectness of the PDF. So Mobile Form upscales the form rendition to make “0.0069 inch” thick borders visible. It uses “1 inch = 72 points = 144 pixels“. At this scale the thickness turns out to be close to 1 pixel and that makes all the browsers happy.

Upscaling by 150% has its own side effects that the form designer should be careful of. Here is the two screenshots of the forms (posted at Adobe Forums) in pdf and in html. You can see the effect of scaling in Mobile Form.

Since Mobile Form is upscaling everything, you should check your text sizes so they don’t look not too big after upscaling. Another thing to note is image, since Mobile Form upscale it by 150% just make sure its picture quality remains good enough.

You can add title, description and also custom properties like shown in the picture below. This meta data makes your form more accessible as this info is read by screen readers also. More info on designing accessible forms can be found at Accessible Mobile Form.

Title specified in this data will appear in the title bar of the Adobe Reader when you open the pdf form. If you want to show the title in Html Form, you can leverage the FormBridge APIs to retrieve the form data.

1
2
3
4
5
6
7
8
9
10

$(function(){
    window.formBridge.connect(
        function(){
            var titleResult = window.formBridge.getFieldProperties("xfa.form..desc.title","value");            if(titleResult && !titleResult.errors && titleResult.data && titleResult.data[0]){
                $(document).attr('title', titleResult.data[0]);
            }
        }
    );
});

XFA Form stores all the metadata associated with the form in <desc> element of the root level subform. Since the name of your root level subform can be different for all the forms, you are rendering with a profile, you have to use a form independent SOM expression. That is why at line 4 of the script, you can see the double dot notation.
In the similar way you can extract any meta data present in the form and use it in html form.

Creating a new Mobile Form profile is very similar to creating a new resource and resource renderer i.e. to create a sling script and a jcr content node if required. I created a sample application package. You can install  the package using http://<lcserver>:<port>/lc/crx/packmgr/index.jsp UI.

Now go to http://<lcserver>:<port>/lc/crx/de page (CRXDE Lite).  Browse the content node and you would notice nodes like following:

A sling:folder node form, then nt:unstructured node leave and template. Mobile Form rendition service, an OSGi service reponsible for generating html5 snippet for the xdp, can also take input from a template child node of the profile node which is leave in this case. If you select profile node leave in crxde lite, you notice the properties of this node like the following:

You would notice one of the properties on the profile node is sling:resourceSuperType which is xfaforms/profile in this case. This is the property that makes any node Mobile Form profile node. This suggests sling to pass on the http requests to this node via profile renderer scripts which is profile jsp in Mobile Form context.

Mobile Form profile jsp page usually takes input from the request parameter but that is not the only way to pass parameters. For example to pass template info to profile jsp, you can create a child node named template in profile node hierarchy and specify template reference like the following:

Using the child template node you can hide the template information from URL of the form. The new URL would be  http://<lcserver>:<port>/lc/content/forms/leave.html without any refresh to the template location.

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:

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:

1
2
3
4
5
6
7
8
9
10
11

<form id="lcforms_xfaform_container" action="/lc/content/xfaforms/submission/default" enctype="application/x-www-form-urlencoded" method="post" target="_self">
<div class="formLoading" id="formLoadingDiv" data-xfadom="&lt;%=formDom%&gt;" data-xfahtmldom="&lt;%=firstpagedom%&gt;" data-xfaresthtmldom="&lt;%=resthtmldom%&gt;" data-xfahiddenobjdom="&lt;%=hiddenObjDom%&gt;" data-xfamergeddom="&lt;%=mergedFormDom%&gt;" data-xfalocaleset="&lt;%=localeset%&gt;" data-internalcss="&lt;%=internalcss%&gt;" data-xfarendercontext="&lt;%=renderContext%&gt;">
 
Loading...
 
<script type="text/javascript">
_initializeXfaLoading();
</script>
 
</div>
</form>

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:

1
2
3

<form id="lcforms_xfaform_container" enctype="application/x-www-form-urlencoded" method="post" target="_self">
<div class="xfaform form1" role="form" data-xfamodel="{}"><!-- form content goes here --></div>
</form>

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:

1
2
3
4

<div class="field textfield TextField1" id="_15" data-xfamodel="">
<div class="caption" role="presentation" data-xfamodel=""><svg> Text Field </svg></div>
<div class="widget textfieldwidget" data-xfamodel=""><input type="text" /></div>
</div>

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.

As per Sling website, Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content. Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.

Mobile Form has a service that generates HTML snippet from XFA form. That html snippet, along with the xfaform css and js, can be embedded into any web page using the sling constructs like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<%@ page session="false" %>
<%@taglib prefix="sling" uri="http://sling.apache.org/taglibs/sling/1.0"%>
<%@taglib prefix="cq" uri="http://www.day.com/taglibs/cq/1.0" %>
 
<%
    String locale = "en_US";
    request.setAttribute("xfaLocale",locale.replace("_",""));
%>
<!DOCTYPE html>
<html>
       <head>
               <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
               <meta charset="UTF-8">
               <cq:includeClientLib categories="xfaforms.I18N.${xfaLocale}" />
               <cq:includeClientLib categories="xfaforms.runtime" />
       </head>
       <body id="formBody">
            <sling:include resourceType="xfaforms/render"/>
       </body>
</html>

Pause and take a look at the highlighted lines 14,15 and 18. Rest of the stuff is pretty standard sling jsp script. We use the recommended practice for including client side libraries. The first includeClientLib is for including the locale specific messages you can modify the xfaLocale parameter to control it where as the other includeClientLib is for including the XFA Runtime.

Sling include @ line 18 is responsible for the html snippet, I mentioned earlier. You can create you page and just add these lines to include client side libs and html snippet to get the form running.

We call the content node and the sling script, responsible for rendering form embedded in web page, Html profile. We call it so because, profile dictates how a form should look like and how it behaves. That means one needs to play with the profile for all the customization required in the form. Mobile Form leaves a lot of hooks in the generated html snippet in order to help the customization.

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.

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.

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.

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.

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

Then 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.