GPI has written a number of blogs about the benefits of FrameMaker 10, since it is one of the most popular source file formats for single-source publishing and high page count projects. There are a huge number of advantages to migrating content into structured FrameMaker with DITA or XML structure. One of the chief benefits is the number of ways that formatting for document translation can be automated, or made virtually “fool-proof.” These benefits are magnified by the number of target languages involved when FrameMaker files go through document translation.
Adobe has recently been hosting a number of “deep dive” webinars that cover virtually every aspect of creating and managing a structured document project in FrameMaker. Fortunately, all of these webinars have been recorded and are readily available. We will reference a few of these helpful video demos as we touch on the highlights of controlling document structure and formatting with structured FrameMaker 10 for document translation.
Unstructured FrameMaker is more limited in formatting for document translation
Many clients still use “regular” or unstructured FrameMaker for source-language documents in preparation for language translation services projects. With enforcement of best practices, consistent use of paragraph and character tags, and minimal “format overrides,” this is usually a successful venture. Ironically, the file format (MIF) used for translating FrameMaker files is generally more error-proof than Microsoft Word. However, there is a significant difference in the way document assets for unstructured FrameMaker files are handled during the translation process.
Pre-translation engineering file processing involves saving FrameMaker documents to MIF (Maker Interchange Format). This is a fully documented, ASCII-based file format that preserves every facet of the document, including all formatting and format definitions. Unlike XML or DITA, there is no true separation of content from formatting. The “template” (master page layout, character and paragraph formats) is literally fused inside the document.
As a result, after document translation occurs for unstructured FrameMaker documents, the MIF is converted back into binary *.fm files. Then, a language-specific template often has to be manually imported into all chapters of a book file. Books typically required 2 or 3 templates, e.g. one for TOC, one for Chapters and one for Indices or Appendices. The management of language-specific templates can be tedious and potentially error prone. Due to the manual nature of this process, additional post-translation format-proofing may be necessary.
Another issue with unstructured FrameMaker is that it is relatively easy to make scattered and inconsistent “format overrides.” An extreme example would be a “body” paragraph that has had indents, font and bolding changed to make the paragraph resemble a “Heading 1.” This, of course, makes global updates to formatting difficult, if not impossible.
How structured FrameMaker and DITA/XML handle formatting
As with conventional DITA or XML applications, structured FrameMaker allows separation of formatting from content. Formatting comes either from an external template or a series of “format rules” that are contained in the EDD (Element Definition Document).
The EDD closely parallels the structure of a DTD, but it contains some commands and rules proprietary to FrameMaker. In an extremely simple structured FrameMaker application, the EDD can simply “map” conventional paragraph or character styles to specific XML or DITA elements.
Why developing formatting for FrameMaker/DITA takes less time
Ironically, the fact that every unstructured FrameMaker document has a ” template” fused inside of it is a huge advantage. This means that any well-formed legacy FrameMaker document can become the basis of the template used for structured FrameMaker. In some cases, a legacy document may need virtually no modification at all to achieve this goal.
Most conventional DITA authoring solutions require the developer to replicate all formatting from legacy Word or FrameMaker documents in CSS or XSLT style sheets. FrameMaker virtually eliminates this step. In addition, the format choices available in the EDD under format rules are an extremely close parallel to the format choices found in conventional FrameMaker paragraph, table and character “designer” menus. There are a number of ways in which you can add formatting to the EDD.
Context-sensitive format rules in FrameMaker 10
Context rules in the FrameMaker EDD fall into two general categories: (a) context rules that are influenced by containing elements and (b) context rules which activate based on an attribute value.
Many users are familiar with “context-sensitive” formatting in structured FrameMaker. Some of the built-in templates, have nested lists and the rules of the EDD will change a list bullet to a dash, if the list item is “demoted” and contained by another list, for instance. In this case, the element formatting is being determined by the containing element.
Although this type of formatting may be accomplished in almost any XML editor, the process for setting up formatting rules in FrameMaker is generally perceived as more intuitive and less complex than those required to create formatting via XSLT.
Context-formatting based on attributes is not as widely known. GPI documented this feature in a joint case study with Adobe, ” Adobe Success Story: Major Medical Device Manufacturer (MMDM).” We also discussed this solution in our previous blog, ” FrameMaker DITA and Translation: Eliminate Round Trip to XML.”
Format changes triggered by a Language Attribute
The following screen captures illustrate how the Lang (language) attribute can trigger automatic format changes via the EDD, which are automatically applied to the XML files when they are opened in FrameMaker:
- This shot shows the source English file formatting for the [note] element in XML:
- This shot shows how the Lang attribute has been set to Bulgarian in a translated version of the file:
- This shot shows the portion of the EDD with a context rule for [note] that is dependent on the Lang attribute being set to Bulgarian. Notice that both the left indent and tab values are increased, and the word “note” is replaced with the Bulgarian equivalent, “Забележка“.
- This final shot shows how the same [note] element is formatted differently in the FrameMaker XML file that has a Lang attribute set to Bulgarian. Notice the substituted text in the paragraph prefix and the increased tab/indent:
Why are formatting rules for XML documents easier for FrameMaker users?
Since FrameMaker has been around for 25 years, there is an enormous pool of talent composed of content creators and editors with at least a moderate set of FrameMaker skills. For a publisher who knows how to create paragraph formatting for regular, unstructured FrameMaker documents, the process of setting up context format rules in a FrameMaker EDD is highly intuitive.
This is because the EDD is actually a structured FrameMaker document, and the structure view will actually prompt the designer with paragraph format elements that may be “legally” inserted in any particular location. The list of available options for formatting very closely parallels how formatting choices are clustered together in the FrameMaker paragraph or character designer.
Benefits of a single template for multiple languages
A few years ago, when the majority of FrameMaker users were using regular (or unstructured) FrameMaker, automated, language-based formatting was not as easy to achieve. As GPI has documented in previous blogs and webinars, it is now possible to have a single structured template automatically provide formatting for more than 28 languages. This includes such language dependent issues as:
- Changing all fonts for Asian languages like the Chinese language , the Japanese language and the Korean language
- Automatically adjusting paragraph prefix text
- Automatically adjusting hanging indents (as illustrated above) to accommodate translated text expansion for words like “note”, “caution” and “warning”
Before the advent of a single template for FrameMaker XML files, most language translation services providers (or your translation agency) had to maintain multiple “look-alike” templates that had only a few differences between them. Obviously, the increased error rate of not updating all instances of “note” in a particular language template was high.
This blog covers just a few of the strengths of structured FrameMaker that you can capitalize on for increased productivity, whether your projects are English-only, or whether you have multiple language document translation projects that span dozens of languages.