Archive for July, 2008

Advanced Typography Options

We’ve added some new typographical options to Designer for 8.2. We now support kerning, horizontal and vertical font scaling and letter spacing.

FontInspector.png

Kerning

Kerning is used to reduce the spacing between glyphs to make text more visually appealing. Designer supports pair kerning, a kerning algorithm that looks at pairs of glyphs and figures out whether the glyphs can be drawn closer together. Certain glyph pairs are highly prone to kerning (like “AV” where the space between the two letters is highly symmetrical) whereas other glyph pairs are not good candidates for kerning. There is no user control over which glyph pairs will be kerned – the kerning is applied based on font metrics and kerning information embedded in the font as well as other algorithmic operations undertaken by Designer.

You can choose to apply kerning to an entire object or to a selection of text – again, whether anything gets kerned is up to Designer, but it will attempt to kern the given text.

If you apply kerning to a selection of text, or if you multi-select objects that have different kerning values, the “Auto Kern” checkbox will display a square rather than a check: this indicates varying kerning states in the current selection.

Font Scaling

Font scaling is used to independently change either the horizontal or vertical sizing of glyphs. Setting the horizontal and vertical scale to the same amount is equivalent to changing the point size (i.e. for a 10pt font, setting the horizontal and vertical scale to 200% is equivalent to doubling the point size. So the result would be identical to setting the font to be 20pt in size.)

Scaling can be applied to an entire object, or to a text selection within the object.

Letter Spacing

Letter spacing is used to force glyphs to render closer together (sort of squishing the letters) or to force letters to render further apart (expanding the text). Unlike kerning, which is applied selectively to certain glyphs that are considered good candidates, letter spacing is applied uniformly to all text.

In order to make letters render closer together, a negative value should be entered. To force the text to expand, enter a positive value.

Like the other properties, letter spacing can be applied to an entire object, or to a selection of text.

The typographical options are fairly straightforward and work like other existing typographical options. Please feel free to post any comments or questions in the comments section.

Hyphenation Under the Hood (HUH)

Designer now supports automatic hyphenation of text on a form. We anticipate that this feature is going to be very popular with some clients (especially with German clients – from what I understand, German is a language that benefits a lot from auto-hyphenation.) In this post, I’ll be providing a summary of how the hyphenation feature works in Designer, along with some “under the hood” descriptions of what’s really going on when hyphenation is used.

The Nuts and Bolts

At it’s base, hyphenation instructions are really an XFA tag <hyphenation> that is a child of the <para> tag. According to the XFA grammar, any <para> tag in the whole form can have a <hyphenation> child and set specific hyphenation settings for that <para> element.

However, we did not choose to expose hyphenation in Designer as a per-<para> property. Instead, hyphenation is implemented on a per-form basis, with each individual text object either having hyphenation on or off.

The way hyphenation works is that the five different variables that control hyphenation are set at the form level and get applied to any object that has hyphenation turned on. The way we chose to implement the form level hyphenation is through the XFA <protos> mechanism. A <proto> is like a snippet of re-usable XFA; you can declare it once and then have any element “use” that proto.

We have one proto definition for a hyphenation node:


<proto>
<field name="designer__defaultHyphenation">
<para>
<hyphenation hyphenate="1" wordCharacterCount="3" remainCharacterCount="2" pushCharacterCount="2"/>
</para>
</field>
</proto>

Then, every object for which hyphenation is turned on gets a <hyphenation> entry on it’s <para> element that uses that proto node:


<para vAlign="middle">
<hyphenation use="designer__defaultHyphenation.para.hyphenation"/>
</para>

How Designer Implements Form-Level Hyphenation Settings

There are actually two mechanisms that come into play when setting form-level hyphenation. The first mechanism is the application level hyphenation settings. These settings can be found under Tools | Options | Formatting. These settings control hyphenation options for new forms. So every new form created in Designer will have these hyphenation settings a a default. The goal of this menu is to allow users to customize hyphenation behavior for all forms they create, so they don’t have to constantly update the Form Properties of every new form.

Tools.png

The second mechanism that comes into play is to change settings on a per-form basis, in File | Form Properties | Formatting. Changing the settings here only affects the current form; new forms will still inherit the settings from the Tools | Options | Formatting menu. Changing the form-level hyphenation properties has an immediate effect on the current form: once the dialog is dismissed, all hyphenated text in the form should change to reflect the new hyphenation settings. This dialog also contains two buttons that are shortcuts for removing all hyphenation from the form and adding hyphenation to all the elements of the form. Note that these buttons have an instantaneous result – you don’t have to press “ok” on the dialog for the action to take place.

Form.png

The proto hyphenation node will only be present if it is needed (i.e. some real node, somewhere in the document, is hyphenated and thus needs to use the proto.) In certain cases, if there is no proto node, but the form has hyphenation settings that differ from the default, then a Hyphenation processing instruction (PI) will be added to the document in order to save the form’s hyphenation settings.

How to Use Hyphenation in a Form

When you are actually working with your form, hyphenation is really simple to use. It’s one checkbox control on the Paragraph Inspector.

Inspector1.png

A couple of “gotchas” with hyphenation on the form:

  • By default, allowing hyphenation of field captions and static text is disabled. This means that the hyphenation checkbox control will be disabled on the dialog if a static text control is selected. It also means that on a control that has both caption and value text (i.e. a TextField), when the hyphenation checkbox is checked, it will fill with a square rather than a check, indicating a dual-state check (where half the control is hyphenated and the other half is not.) In order to change this behavior, enable the “Allow Hyphenation in Text and Field Captions” option in Tools | Options | Formatting (for all new forms) or in File | Form Properties | Formatting (for the current form).
  • Another situation where the checkbox may fill with a square rather than a check is if multiple objects are selected and some of them have hyphenation enabled and others have it disabled. The checkbox will show the “mixed” square indicator in this situation as well.

Comments on Compatibility

Hyphenation works with XFAF. However, hyphenation cannot be applied to background content.

Using hyphenation can result in target version warnings, since not all versions of Acrobat support all types of hyphenation. For the most part, hyphenation in value text is not supported in earlier versions of Acrobat (< 9.0). Hyphenation in boilerplate text is supported in older version of Acrobat for static forms. If the form is dynamic, then hyphenation of boilerplate will not be supported in older versions of Acrobat (< 9.0).

One last note on compatibility: there is a risk that using hyphenation could cause text shifting in newer versions of Acrobat. Hyphenation depends on hyphenation dictionaries to figure out where to hyphenate text. Hyphenation dictionaries can change over time: it is conceivable that new dictionaries could be introduced that would change where hyphenation points occur, leading to changes in text layout for hyphenated text. These changes would probably be very minor, but it could lead to a difference of adding/losing a line of text. The risk is fairly small, but it does exist. We strongly urge customers who have forms that are sensitive to text shifting not to make use of hyphenation.

Hyphenation and Fragments

(The following is straight from the functional specification for hyphenation:)

Hyphenation in fragments works in the same way as hyphenation in regular forms. That is, any object that is hyphenated in a fragment will have a <hyphenation use=“designer__defaultHyphenation.para.hyphenation”/> child defined under the appropriate <para> element.

When a fragment is created in a separate XDP file, if any object in the fragment contains hyphenation instructions then the fragment will be created with a <proto> element on the root subform that contains a <hyphenation> child inside a named field that is a copy of the <hyphenation> definition from the original form. The use attribute does not need to be updated, since the SOM of the hyphenation proto is the same in the fragment as it was in the original document.

If a fragment is defined within an existing XDP, nothing changes in regards to hyphenation; the <hyphenation use=“designer__defaultHyphenation.para.hyphenation”/> elements are still valid, and continue to point to the root subform’s <proto> <hyphenation> element.

In both of the cases above, when a fragment is referenced from another form, it (potentially) has different hyphenation settings than the form that is referencing the fragment. The fragment’s hyphenation settings are self-contained within the fragment and separate from the referencing form’s fragment settings.

When a referenced fragment is embedded within a form, it loses its unique hyphenation settings; any <hyphenation use=“designer__defaultHyphenation.para.hyphenation”/> elements will be changed so that the use attribute points to the SOM of the root subform’s <proto> hyphenation node. Or, in other words, the fragment will now inherit the form’s hyphenation settings, rather than having different hyphenation settings that are defined in the fragment. This could potentially lead to a change in appearance and layout when a fragment is embedded.

If a hyphenated fragment is embedded within a form that does not have any hyphenation, then the fragment’s hyphenation will be lost (i.e. it still inherits the form’s hyphenation settings, namely “no hyphenation”).

To Conclude

This was an overview of the Hyphenation feature from an “under the hood” perspective. For details on how the feature works from a functional point of view, please read Designer’s Help documentation.

An example of splitting text across two fields

I went on a customer visit and was asked to solve an interesting problem. Basically, this customer had a regulatory PDF form. The form’s layout couldn’t change, and at the end of a workflow process, the form was printed as a document of record. This form was very complicated, with lots of special logic (i.e. “if field 2b is filled, then options 7a, b, and d are no longer available”.) The customer opted to try out Adobe’s Form Guide technology to make the form filling experience better, but once the Guide was complete, we had to take the data from the Guide and push it back to the PDF form (using LiveCycle) and then print the PDF form to paper.

This form had many small fields with instructions indicating that if the field couldn’t contain all the info, to add an appendix page with the rest of the text. Now, in most cases, we would encourage clients to make fields growable, so that they will just expand to fit the text put in them and all the subsequent form content will move down. However, in this case, due to the need for the form to preserve it’s original layout for printing, we couldn’t do that.

It was actually hard to solve this problem: we tried many different scenarios, but most of them were dead ends. The essential problem we kept running into was that the XFA model just doesn’t provide the information you would need to calculate or extrapolate how much text can fit in a given field.

The only solution we came up with that worked fairly well is in the form below. It involves using a fixed-width font in the fixed field, so that reasonable assumptions can be made about how much text can fit into a given field. There’s script that parses text and splits it between two fields. The script is heavily commented, so hopefully readers can figure out what’s going by reading the code.

A form that splits text between nodes