RE: Frame+SGML?

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:48 PM 6/17/99 +0200, Peter Ring wrote:
>The one thing about structured Framemaker+SGML documents that appeals most
>to me is your first point. I work part-time as a technical writer and
>appreciate very much the conveniences of structured documents: focus on
>contents while you write, and much easier to rearrange structure.
>  But I'd also like to stress the other part of the equation: given a
>structured document and sophisticated formatting rules, it is much cheaper
>(in terms of manual labor) to obtain a typograhically pleasant and correct
>result.
>  Instead of abusing markers and silly 'invisible' paragraphs, you can use
>attributes to carry information not present litterally in the text. And you
>can set up the EDD to automatically make those small adjustments that
>otherwise call for manual overrides or a paragraph catalog the size of a
>phonebook.
>
>I wonder if these benefits of FrameMaker+SGML would be more widely known if
>the initial price were not so steep: one FrameMaker+SGML license is $2K, and
>then you need to have someone develop an EDD. It is nice that Adobe
>published a collection of unstructured templates for various types of
>documents, but there's also a dire need for good examples of structured
>templates.
>
>I'd like to add that the EDD has shortcomings. It is almost a programming
>languages, except it lacks those general features of most programming
>languages that enable you to extend the language itself. Why is it not
>possible to save numerical or string values for later reference? Why can't I
>evaluate a simple expression in order to calculate a value? Why can't I
>define new data types and new functions?

>In my day-time work, we had to find a way around these shortcomings for a
>particular product (a periodical with a somewhat complicated layout). We
>simply don't use an EDD and read/write rules. First, we investigated using
>the FDK to add the features that we needed, but found it too cumbersome.
>Now, we've taken to use OmniMark to translate SGML source files to MIF; this
>looks like a general solution that is easy to maintain. Sadly, this also
>reduces FrameMaker+SGML to a page composition engine.

==================================================================
Well, I use choice-type formatting attributes to:
+ Produce page/column breaks
+ Select Paragraph Horizontal Alignment (left, right, center, justified,
alignment on a decimal point)
+ Select Table Cell Vertical Alignment (Top, Bottom, or Middle)
+ Select a Style (Bold, Italics, Underlined, etc.)
+ Turn Autonumbering on or off, or specify a particular type of autonumbering.
These selections are implemented by format rules that call Format Change
Lists for their implmentation.

But, unfortunately, the EDD has no way to take specific attribute values
(e.g., for line spacing, space above/below, indents) and apply them as
format rules. This is indeed a serious shortcoming. I usually try to get
around it by using choice type attributes that select incremental values
(e.g., 0, 1, 2, 3, 4, etc.), where each choice has a format rule that calls
a Format Change List which equates the choice value to a particular
dimensional value (e.g., 0 = 0 pts, 
1 = 3 pts, 2 = 6 pts, 3 = 9 pts, 4 = 12 pts, and so on).

All of these choice-type formatting attributes have a default value, which
corresponds (usually) to the default formatting of the format-rule-specified
paragraph tag in the template. Consequently, authors only need to fiddle
with the formatting attributes when they need some additional formatting
that is not provided by other format-modifying context rules in the EDD.

If you are starting with an SGML source to be imported rather than with a
document that was authored in FM+SGML, the source will probably not have
these formatting attributes, but they will take on their default values when
the SGML source is imported into FM+SGML. If the EDD's format rules and the
template are properly designed, the need to use these formatting attributes
will be the exception rather than the rule.

It's also possible to clone multiple copies of the EDD, where the only
difference between them is in the values specified in some of the format
change lists. This capability, combined with the capability to create many
different templates, where the same Format-Rule-specified tags are formatted
differently in each template, make it possible to produce widely varying
formatting from the same EDD. 

In most cases, I believe the methods described above to be better and
cheaper than having to resort to something like OmniMark to do the formatting.


     ====================
     | 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
10044 Adams Ave. #208, Huntington Beach, CA 92646
---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.   **