Understanding Borders and Margins in Flowed Layouts

Flowed Layouts

At Avoka, we’re big fans of flowed layouts in Designer. There are a number of reasons for this, some fairly obvious, others less so:

  • If you’re going to use features such as repeatable sections, expanding tables, or hide/show logic, you have to use flowed layouts – as the expanding sections grow, the sections below flow down the page. If you don’t use flowed layouts, the expanded sections will just flow over the top of the ones already there.
  • In many ways, using a flowed layout is a much more maintainable way to build a form. If you use positioned layouts, and need to insert a new field somewhere in the form, you need to re-adjust all the fields below to accomodate the new field. However, if you’re using flowed layouts, all the fields below will simply shift down, and there’s nothing extra to do.
  • Flowed layouts take away a lot of the pain of lining fields up. In a positioned layout, you need to use snap-to grids, rulers, explicit x/y coordinates, in order to get fields lined up. In flowed layouts, you just drop the fields into a flowed sub-form, and they will all automatically line up.

Unfortunately, flowed layouts can be a little difficult to get your head around. With a positioned layout, you can simply drop a field on a form, resize it, and drag it to wherever you want. With a flowed layout, Reader takes care of a lot of the positioning for you, so you sometimes have to use some tricks to get the layout that you want.

This article talks about some of the difficulties with flowed layouts, as well as showing some of the tricks we use to get things looking the way you want them.

A heading with a thick underline

Here is a basic heading as we might insert it into a XFA form. It consists of a subform, and a heading text object within the subform. We’ve put two versions of the same heading into a vertically flowed layout.

Basic Heading

The yellow background and the blue/red border are there just to show where the different subforms start and stop.

Let’s imagine we want to add a solid line below the heading, creating an underline effect. There are several ways to achieve this, including adding a line object, or adding a separate subform with a background color. In this case, we’re going to achieve the effect by adding a bottom border to the object. For the sake of illustration, we’re going to add an 4mm border, which is probably a bit larger than you would normally want – but it helps to show what’s going on.

Border Properties

Once we add the border, we get a form that looks like this:

Bleeding into content area

This is really interesting. What we see is that the border doesn’t increase the size of the subform – the border actually overlays both the subform above and below. With a very thin border, this is usually unnoticable, but with a thick border like this, this causes the border to overlay the text both above and below.

There is actually a very good reason that Reader paints half the border above and half below – it means that if you have two text fields, for example, both with borders, immediately above and below each other – both borders will overlap, and you’ll only get a single width border, rather than an ugly double width border.For example, here are two rectangles with 1mm borders in a flowed layout:

5b.OverlappedBorders

As you can see, despite they fact that there are actually two borders at the boundary, because they each overlap half up and half down, the effect is a single width line.

But this isn’t quite what we want in this case.

Let’s add a background fill to the lower subform. This results in the following:

Apply Background

From this we can see that Reader “paints” the subforms in a particular order. First the top subform, then the border, then the lower sub-form. The painting of the lower subform overlays the border. This doesn’t solve our problem, because we only have a 2mm border.

In order to fix this, the first thing we need to do is add a bottom margin to the top subform. Adding a margin does increase the size of the subform. It also instructs Reader to not lay out any fields within the margin area, thus ensuring that the text object will not be overwritten. We need to make the height of the margin one half of the height of the border (or greater), since only half the border is painted in the upper subform. The margin settings are shown below:

5.marginproperties

This results in the following:

5a.partialresult

We’ve eliminated the overflow on the upper subform. Now we need to get rid of the overflow on the lower sub-form. One way to do this would be to add an upper margin on the lower subform. However, this puts a requirement on whatever element we put below the heading to implement the upper margin. It would be much better if we could solve the problem purely within the upper subform itself. The way to do this is to wrap the upper subform in another subform (right click in Designer and select “Wrap in Subform”), and then add another 2mm margin to that subform.

The nested subforms are shown here:

6.outersubform

This finally gives us the result we want – a 4mm bottom border without any overlays.

7.finalresult.

Conclusion

While this has been a slightly contrived example, we hope that it illustrates some of the subtleties of borders and margins in LiveCycle Designer and Reader. This also serves as a useful technique for achieving thicker borders in flowed layouts.

A Quick Way to get to the Script Editor in Designer

When you first start up Designer, the script editor is only half visible just underneath the toolbar. Usually I make it a little bigger by moving the thumb down a bit, like this:

ScriptEditor - default

Then I double click on the thumb to move it all the way to the top, and double click again to re-expand.

But this is very inconvenient. The script editor is not really big enough to see bigger blocks of script, and if I increase its size, it takes up too much of the screen real-estate that I need for actually designing my form. So I end up continuously making it bigger and smaller depending on what I’m doing. Very irritating.

Here’s a simple way around this.

Firstly, set up a keyboard shortcut to toggle the Script Editor visibility. Use the Tools/Keyboard Shortcuts… menu, select Product Area = Window, find the Script Editor command. Then click in the “New Shortcut” field, press F4 (or your shortcut of choice), and click Assign.

KeyboardShortcut

Then re-arrange your Script Editor to suite your needs. My favourite is detached from the main window (or undocked), and fairly large, as shown below:

ScriptEditor Undocked

There is a bit of a trick to get this right, because as soon as you make the Script Editor a bit large, it will try to dock whenever you move it. So…

  • To undock it, double click on the move bar of the Script Editor. (The move bar will appear either at the top or left of the Script Editor, depending where it’s docked.)
  • Then reposition the Script Editor, NOT by moving it, but rather by resizing both the top left and bottom right corners. Resizing won’t cause the Editor to dock, whereas even the slightest movement can.

From this point on, a single F4 keypress will toggle the Script Editor on and off, and I always have the script editor just where I need it when I need it.

Many thanks to Stefan Cameron for this trick.

What is a SmartForm?

Heard about SmartForms, but confused by the jargon? Never heard of SmartForms, but interested in the latest developments in electronic forms?

This blog provides the need-to-know facts about SmartForms. For a full overview, please watch SmartForms – the next generation of electronic forms.

Running time: 13 minutes
Content: What is a SmartForm?
Demo of three SmartForms in action
Why SmartForms?
Who is using Smartforms?

SmartForms

A SmartForm is an electronic form used by your customers, staff and partners to apply for products and services.

Key capabilities include:

  • perform complex calculations
  • dynamically display content as it is required
  • perform sophisticated validation of the data
  • lookup data from remote systems
  • securely submit the data to your organisation’s systems

Geneaology of the Electronic Form

Not all electronic forms are equal. They differ in how smart they can be in making it easy for users and ensuring that you capture high quality data.

Electronic forms can be categorised into:

  • Print form downloaded from your web-site, printed, completed by hand and posted/faxed to your organisation
  • Fillable form downloaded from your web-site, filled-out on screen before being printed and posted/faxed to your organisation
  • SmartForm downloaded from your web-site, filled-out on screen and submitted electronically

Print Form

The only electronic aspect to this is in its distribution. You face the same challenges as paper of interpreting hand-writing, handling forms that have been incorrectly filled-out and manually entering the data into your systems. According to the Australian outsourcing company review of 2006, 40% of forms contain missing information. Each of these failures result in higher costs and lost sales opportunities

Fillable Form

Fillable forms perform basic validation on the data as it is entered and will print an easy to read form. You will typically need to re-key this data into your back end systems. Optical character recognition (OCR) is feasible with fillable forms if you have the necessary infrastructure.

SmartForm

The most significant development in electronic forms since their inception. For the first time, it is now possible to guide novice users through the completion of complex forms in a highly engaging experience.

SmartForms presentation at BFMA

I was happy to accept an invitation to present at the BFMA region 8 September meeting.

I chose to talk about SmartForms; I described some of the innovative work that has been performed in Australian government over the last four years and shared some lessons learnt from the Red Tape Blueprints project that was delivered for a consortium of 41 NSW councils.

I ran the webinar on Adobe Connect and present the full recorded session below in four parts:

  • Part 1: What is a SmartForm?
    Demo of discovering a SmartForm
    Demo of filling out a Smartform
    Demo of user’s submission history
  • Part 2: Why should you care about SmartForms?
    Demo of eForms benefits calculator
    Leading SmartForm projects in Australian government
    Introduction to Red Tape Blueprints case study
  • Part 3: Red Tape Blueprints solution
    Red Tape Bluepirnts challenges overcome
  • Part 4: Demo of SmartForm submission
  • Part 5: Demo of providing attachments
    Demo of making payment
    Demo of signing a receipt

Part 1

Part 2

Part 3

Part 4

Part 5

About BFMA

BFMA, or the Business Forms Management Association, formed 50 years ago to address the unique educational and networking needs of forms designers and managers. With today’s technology, the forms function has broadened in scope to include everything from traditional paper forms to electronic data capture and the databases and applications that support it.

BFMA region 8 (Asia Pacific) is lead by Jessica Enders at Formulate.

Pre-populating forms with LiveCycle ES

Summary

The recommended pre-population technique is on the server as part of a Livecycle ES process. This provides the best user experience and allows leverage of the full power of LiveCycle ES. This is the default implementation for LiveCycle forms rendered as Form Guides or HTML, as you already have the infrastructure in place for rendering these formats.

A light-weight alternative is available for PDF forms: direct web service calls from Reader/Acrobat that requires little or no server infrastructure.

The most common approach for PDF is to pre-populate user data, for instance name, address and contact details for a known user, in a LiveCycle ES process on the server and then use web services from the client to lookup data from large data sets or perform complex/shared validations.

Pre-populating on the server

Pre-population of data into LiveCycle forms on the server is implemented in a LiveCycle ES process. The three core services to enable this are:

  • Forms Data Integration (FDI) – for pre-population of XML data into a PDF. This service is bundled with several LiveCycle solution components including Process Management and Reader Extensions
  • Forms ES – for pre-population of XML data into an XDP and conversion to PDF, Form Guide or HTML. This is for use cases that are only supported by XDP, including dynamic importing of form fragments
  • Output ES – for pre-population of XML into XDP or PDF and conversion to a read-only or printer-ready format

A typical user experience would be:

  1. User logs into a web-site or portal
  2. User clicks on a link to a form
  3. A server web component (any HTTP technology including servlets, jsp, PHP and ASP.NET) handles the request and calls a LiveCycle process, passing a form ID and the user’s ID (either as a web service or using the LiveCycle APIs)
  4. The LiveCycle process retrieves the form based on form ID
  5. The LiveCycle process retrieves user data based on the ID and generates an XML file
  6. The form is pre-populated using one of the services above
  7. The pre-populated form is returned to the web component which is displayed to the user

Avoka provides a pre-built web component to simplify this implementation – process invoker.

Pre-populating from the client

PDF forms provide the functionality to lookup data directly from Reader/Acrobat using a web service or database lookup. An explanation of how this is implemented is provided by Adobe livedocs.

Web service pre-population is the prefered approach. The database lookup requires that ODBC data source names (DSN) be set up on each user’s machine that will use the form. This may be useful for testing, but is infeasible for production forms. It is not scalable for internal forms and impractical for externally facing forms.

A typical user experience would be:

  1. The user navigates to a web-site
  2. The user clicks on a link to a form
  3. An empty form is displayed within the browser (inside the Acrobat plug-in)
  4. The user enters a customer ID and clicks a button
  5. The Acrobat plug-in directly calls a web service, passing in the customer ID
  6. The web service returns the user’s data which is displayed within the form

Comparison Matrix

Pre-populating on the server Pre-populating from the client
User experience The form is already customised for a known user when it is viewed The form is not personalised to the known user when it is first viewed. The user has to re-enter identifying information into the form and perform an action, for instance click a button, for the web service to be called
Maintenance Changes to the pre-population service can be made in one central location and does not require changes to or re-distribution of forms Changes to the pre-population service may require changes to and re-distribution of forms
Data sources Pre-populated data can be retrieved from multiple sources and transformed by the LiveCycle process before being pre-populated into the form Multiple web services can be used from within or outside the organisation
Infrastructure A server installation of LiveCycle ES is required A lighweight solution that can be implemented with little or no server infrastructure. Server infrastructure is only required to provide access to the form, if it is not to be distributed offline, for instance by email or on CD-ROM/DVD, and to expose web services from your organisation
Development tool Implemented with LiveCycle Workbench Implemented with LiveCycle Designer
Offline support The user must be logged in and online to view a new form. They can then save the form to their local machine and work offline The user can either view the form from a web-site or receive it in an email or on fixed media, for instance cd-rom or memory stick. The user must be online to call the web service
Technical limitations None. LiveCycle ES can handle different form types, data sources and transformation requirements Web services in anything that is not document literal style or returns multiple responses requires custom codingPassword-protected web services cannot be called from a form

Users behind an NTLM authenticating proxy must use Adobe Reader/Acrobat version 9.0 or higher. Typically, this only affects users on corporate environments