Re: Format rules v. para and char formats in FM+SGML

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:36 AM 8/27/01 +1000, hedley_finger@myob.com.au wrote:

>Many of the structured document EDDs I have looked up have no char formats
>and only one para format, Body.  All other typographic specifications of
>elements are done by format rules modifying the properties of the basic
>Body para format.
FORMATTING INHERITANCE AND PARAGRAPH TAGS
For text container elements that become paragraphs, FM+SGML first looks for 
a paragraph tag in the format rules for that element. If no paragraph tag 
is specified, FM+SGML searches upward in the structural hierarchy for an 
ancestor element that specifies a paragraph tag. That tag is selected for 
formatting the descendant element.

Then, FM+SGML moves downward through the structural hierarchy, picking up 
format changes along the way which are also applied to the descendant 
element. The approach you describe above typically results in ancestor 
formatting inheritance at all levels of element structure. Except in very 
simple structures with very simple formatting, allowing this to happen will 
usually cause grief.

In most of the EDDs I've designed, nearly all such ancestor hunting for 
format information is stopped. Instead, each text container element 
requiring a paragraph tag has a format rule that specifies a single Element 
Paragraph Format, or, if different paragraph tags are required in different 
contexts, the format rules specify  different paragraph formats for some 
contexts. In most cases, however, a single Element Paragraph Format 
suffices, and additional format rules specify (by referencing format change 
lists) variations in format that are required in different element contexts.

The foregoing description does not imply, however, that the EDD specifies 
container element specifies an unique Element Paragraph Format for each 
text container element. That is, the same base paragraph format may be used 
in many different text container elements.

FORMAT RULES IN THE EDD SHOULD REFERENCE FORMAT CHANGE LISTS
In almost all cases, format rules in the EDD should refer to Format Change 
Lists, all of which are at the back of the EDD. These format change lists 
provide the formatting details for the various contexts defined in the 
format rules for each element. There are several advantages to this approach:
A. Adaptability
Almost any formatting change can be made without affecting the format rules 
themselves. For example, you could create several variations of the same 
EDD, all having the same format rules and format change lists, but some or 
all of the format change lists could have variations in the formatting 
details to accommodate different document delivery requirements.

B. Eliminating Clutter
When the formatting details are embedded within complex arrays of format 
rules for an element used in many different contexts, the format rules 
become intractably difficult to manage, understand, and modify. This 
clutter is eliminated by placing the formatting details in format change 
lists that are referenced in the format rules.

C. Reusability
Often, the same format change list can be referenced in many different 
format rules for the same or different elements. By properly structuring 
the EDD format rules, the formatting for any given element context may be 
specified by the composite of two or more format change lists that are 
referenced in different format rules for the same element. For example, in 
multi-level lists, one set of format rules might reference the format 
change lists that set the indentation for different contexts, and another 
set of format rules might reference the format change lists that specify 
the autonumbering for different contexts. Thus, for any given element 
context, the formatting is a composite of the applicable indentation format 
change list and the applicable autonumbering format change list. I've 
developed EDDs in which the paragraph formatting is produced by the 
composite of as many as 4 or 5 format change lists, all of which are 
applicable to a particular element context.  "Atomizing" format change 
lists in this way can drastically reduce the size and complexity of the 
EDD, and makes it much easier to manage and modify.

DETERMINING THE SET OF PARAGRAPH TAGS THAT ARE TO BE REFERENCED IN THE EDD
In general, I try to avoid EDD format rules that modify the following 
paragraph properties:
Line Spacing
Font Family
Language
Pair Kern
Widow/Orphan Lines
Hyphenation
Word Spacing
Automatic Letter Spacing
Table Cell Margins

Consequently, I define separate paragraph tags for each case where any of 
these parameters must be varied, and specify the appropriate tag as the 
Element Paragraph Format for each text container element. Usually, there 
are also additional special cases where distinctly unique  paragraph tags 
should be defined and specified in the EDD.

The result of this approach is that, after the EDD's element definitions 
are imported into a new template, the template designer specifies, for each 
EDD-specified paragraph tag added to the template's paragraph catalog, 
those properties which will not be modified by any EDD format rules, and 
specifies default values (which may be modified by format rules) for the 
other properties. In this way, two or more templates, each having the same 
set of EDD-specified paragraph tags, can have variations in those 
properties not modified by EDD format rules. This allows the same EDD to be 
used for many different document delivery requirements.

DETERMINING THE SET OF CHARACTER TAGS TO BE REFERENCED IN THE EDD

EDD-specified character formatting is often required in Prefix and Suffix 
rules, as well as in format change lists that include autonumbering 
specifications. Also, Text-range-type text container elements must often 
specify character formatting.

In these cases, character tags, rather than format-rule-specified 
formatting details, should be used so as to allow template designers to 
create multiple versions of the template, each having the same set of 
EDD-specified character tags, so that variations in the formatting of these 
tags are possible to accommodate different document delivery requirements.

>It seems to me that, especially when migrating from legacy unstructured
>documents to FM+SGML, a lot of headache would be saved if elements were
>mapped onto existing para and char formats.

Hedley, I assume you're using FM+SGML Structure Rules Tables to accomplish 
the conversion. In the Structure Rules Tables, you map the unstructured 
document's paragraph and character tags to elements. In such conversions 
there are often one-to-many mappings (i.e., a particular tag maps to two or 
more elements depending on context), and even many-to-one mappings (i.e., 
two or more different tags map to a single element). However, if one-to-one 
mappings predominate, there might be an advantage to specifying, in the 
EDD, the same tags used in the unstructured documents. In that case, you 
would import the EDD's element definitions into the unstructured document 
template, resulting in the EDD-specified paragraph tags  being formatted 
identically to the way they were in the unstructured documents. However, 
you must first make the tagging consistent across all the documents to be 
converted else you'll have to create a different Structure Rule Table for 
each variation.




====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
177 Riverside Ave., STE F, #1151, Newport Beach, CA 92663
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **