Archive for April, 2013

Mobile Form upscaling

Mobile Form rendition of an XFA form is almost similar to PDF Form rendition in terms of behavior and appearance. Some of the dissimilarities are discussed in Mobile Form Vs PDF Form post. In this post, I’ll discuss one key difference that a form designer should take care while designing the XFA Template and that is where it is so critical to preview your templates from the designer itself.

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.

Upscale

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.

 

Access Metadata from XDP

In this post, I’ll address a use case where in profile you want to access data from the rendered form. Sometimes, you might want to access metadata associated with the form. You can add metadata to the form using the Form Properties option of the File menu in LiveCycle Designer.
form_prop1

 

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.

form_prop_diag

 

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.

Hide template reference

In this post I will describe how one can you pass template reference without using request parameter. The default profile of Mobile Form takes all the parameters like template reference, data reference etc through HTTP request parameter. If Mobile Form is deployed to serve the forms on internet then you might not like to expose such URLs on public forums. That is probably because it would expose the internal repository structure to the end user.
With the default profile, a form url would like http://<lcserver>:<port>/lc/content/xfaforms/profiles/test.html?contentRoot=repository:///Applications/FormSubmission/1.0&template=SimpleForm.xdp. This link contains the template reference present in your LC repository which you might not like to expose. In this post, I will cover how you can create a new profile to cope up with this problem.

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:

profile1

 

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:

 

 

profile3

 

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:

profile2

 

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.