Skip to main content
Inspiring
July 3, 2009
Question

Formatting catalogs vs. explicit formatting properties in an EDD

  • July 3, 2009
  • 1 reply
  • 1419 views

The bulk of the discussion on "Exporting Paragraph Catalog to EDD" (http://forums.adobe.com/message/2083552#2083552) deals with whether EDDs should apply specific formatting properties or apply named formats defined in the document's paragraph or character catalogs. Since that is a worthy topic in its own right, I am giving my response in this new thread.

Frankly, most of the responses to this part of the discussion are simply expressions of personal opinion. I'm a proponent of personal opinion and one of FrameMaker's strengths is its flexibility in supporting different users' preferences. However, I would like to point out in this case there are various technical reasons to use one or the other of these particular techniques.

1. The ability to specify individual formatting properties allows an EDD's context and level rules to specify context-sensitive variations of a base format. For this reason, the term "hierarchical styles" can be used to refer to this approach. Hierarchical styles allow an EDD to apply relevant formatting in the definition of the element that triggers that formatting.

Suppose, for example, that list items contain a sequence of paragraphs and notes and that notes contain a sequence of paragraphs and lists. Further suppose that both lists and notes are variations of the document's base format in which lists are indented and notes are italicized. One approach in the EDD is to assume the paragraph catalog includes formats called Body, Indent, Italics, and IndentItalics. The definition of the paragraph element can then apply one of these formats depending on whether the paragraph is within a list, within a note, within both, or within neither. Alternatively, the definition of the list element can change the indentation without considering whether or not the content is italicized and the definition of the note element can change the angle without considering the indentation.

Using hierarchical styles mean any changes to the base format (by default, Body) do not have to be replicated in numerous variations. The paragraph catalog thus is smaller and hence easier to maintain. Furthermore, no explicit testing for lists within notes or notes within lists is needed. Finally, the formatting is specified where it logically belongs. The developer specifies the list-motivated indention when defining the list element and the note-motivated font change when defining the note element instead of worrying about both of them when defining the paragraph element.

2. If an EDD is based on existing unstructured documents that already have rich paragraph and character catalogs it is often practical to use the existing formats rather than to copy their properties into the EDD.

3. There are numerous FrameMaker plug-ins that operate on paragraph and/or character formats. If the organization's workflow involves such plug-ins, hierarchical styles cannot be used.

4. Using formatting catalogs allows one EDD to be used with multiple templates that define the named formats in different ways. For example, variant templates may use language-specific autonumbers or set indentations and tab stops for different page styles.

Furthermore, note that an EDD developer can choose to refer to formatting catalogs or use hierarchical styles for some cases and use the other technique for others. For example, the developer may refer to the paragraph catalog for various levels of section headings but use hierarchical styles for variations of body paragraphs (such as the lists and notes discussed above).

        --Lynne

This topic has been closed for replies.

1 reply

Harald E Brandt
Known Participant
July 21, 2009

Lynne, an excellent tutorial!

I hope you do not mind if I add to this thread with some additional considerations, and mention the guideline I have followed?

I especially appreciate your number 1 and number 4, since I think they both are very important, and my own guideline very much adheres to what is said in those sections, although I have some twists.

Historically, while working in unstructured FM, I have numerous times had to change both fonts and languages in far too many formats! I deeply hate it! For each of these changes, I have been forced to painstakingly go through every single paragraph format, because there is no inheritance at all! It is a nightmare to go through each time if you have many formats! And there is always something I miss in the first round! Avoid at all costs!!

The language issue is especially important if you work with manuals that are to be translated into many languages! I personally only author in three different languages: US English, British English, Swedish. But when documents shall be translated into several languages, there MUST be an easy way to change the language so that hyphenation becomes reasonable. And for certain languages you also have to change fonts. With FM 7, which wasn't even Unicode-aware, any non-western language had to be given a suitable font for the language category! I created "language files" that had these adapted paragraph formats, so I could import them into the translated documents.

So, the implications of the above say that the paragraph catalog should be kept short, but also that both language and font should be set in the paragraph catalog and not the EDD.

I've also had to change the width of side heads several times. But if you change the width of the side head, the indentation and tabs of paragraphs that span the column into the side head will also have to be changed! So, in conclusion: let the EDD do that work; specify the size of the side head, the column width, and any special indentation in variables of the EDD so it is very easy to change and maintain consistency!

Reuse of the EDD: It is desirable to be able to use the same EDD for as large a category of documents as possible, although it is okay to make small variations of the EDD by importing different variables to support completely different layouts, such as different size of side heads. Fonts for title and various headings may be different in different kinds of documents or different organizations, and it may change over time.

The guiding principle

So, the above led me to the guiding principle:

Use paragraph formatting only where there might be a future need to change fonts, or to change the language. Never specify font family names in the EDD! But let the EDD do the rest, unless it can refer to a named character format, since those can have several properties set to As Is, which means that a character format can act as a "format modifier", only changing a single property.

The result

The result of the above principle is that I have a paragraph catalog of only about 20 items. Of course there is Body, and CellBody since they usually use different fonts. Equation, FigureCaption, TableTitle, Author and Title. A Header, and separate paragraph formats for all the headings, since, in a new type of document, headings may very well need new fonts (and sizes).

The character format catalog, on the other hand, is much longer — most of them have several properties set to As Is, so they are not as cumbersome to maintain.

  --Harald

Ian Proudfoot
Legend
July 21, 2009

Harald,

One of the major strengths of FrameMaker is that there's more than one way to achieve the desired results. I choose a different set of compromises, but with equally good results.

I am currently working on projects that support a minimum of 25 languages within a single structured FrameMaker book. We achieve all of the formatting including font changes for Asian languages from within the EDD and with a single structured template. At the top level element the xml:lang attribute is used to set the language for the current file. All language based formatting changes respond to that single attribute. I find it easy to manage during development and the user's love it.

Within the EDD, rules to set the language are only needed for each highest level element and any table elements. Font names are stored in User Variables so they would only need to be changed in a single location.

Sure, this is a little different to your working practices, but it may be a suitable alternative for some.

Regards

Ian