Re: Clear char overrides, keep char formats?

[Dan Emory <danemory@xxxxxxxxxxxx>]

This is a very belated (and lengthy) reply on this thread, but I finally 
got around to it.

All of the complications involved with removing character format overrides 
described below by Thomas are eliminated when you create structured 
documents in FM+SGML, where the EDD specifies text-range elements for the 
formatting of character strings within paragraphs. Typically, for each such 
text-range element, the EDD specifies a character tag included in the 
template's character catalog, and the desired formatting is accomplished by 
"wrapping" the character string with the appropriate text-range element.. 
It's also possible to use different character tags for the same text-range 
element, based on element context, attribute values, or a combination of both.

FM+SGML handles case b (two or more character tags applied to the same 
character string). In FM+SGML, this is accomplished by "wrapping" the 
character string two or more times--once for each applied text-range 
element. Unlike ordinary FrameMaker, FM+SGML will remember all of the 
applied character formats, because each is associated with a different 
text-range element.

The real bugaboo in ordinary FrameMaker is its inability to find and wipe 
out all ad-hoc character format overrides in a document. In an FM_SGML 
structured document, this would correspond to any applied character formats 
not accomplished by wrapping character strings with text-range elements.The 
removal of these overrides is accomplished automatically by simply 
importing the document's element definitions back into itself with Remove 
Format Overrides turned on. This action also wipes out any ad-hoc 
modifications to paragraph formats, restoring such paragraphs to the 
EDD-specified formatting.

Another capability of FM+SGML is validation of the document's structure. 
Any violation of the EDD''s structure rules, including omission of required 
structural elements, is auto-detected, and the required corrective action 
is indicated at each invalid point in the document structure. For those who 
gag on the idea of forcing authors to adhere to a rigid structure, I'd like 
to point out that the structure rules in an EDD can be as loose as you want 
them to be.

These two actions (elimination of all illegal formatting and 
detection/correction of all invalid structure), normally performed by the 
Quality Assurance function, guarantee that the document will fully conform 
to the formatting and structure specified in the EDD. In effect then, the 
EDD functions as an automatic enforcer of the formatting and structure 
rules in the EDD. Thus FM+SGML becomes an automatic enforcer of your style 
guide.

Once authors realize that any format overrides or invalid structure in a 
document will automatically be detected and wiped out/corrected as part of 
the Quality Assurance activity, they have no choice but to stop cheating.

In addition to the features described above, structured documents created 
with FM+SGML also provide the capability to include metadata (data about 
data) in the form of element attributes. Metadata is hidden (like markers 
and conditional text) in the printed or displayed document, but it is still 
accessible. Metadata can be used for many diverse functions, including 
formatting, information retrieval, revision and version tracking, and many 
other document management functions.

Absolute consistency in formatting and the use of defined structure, as 
well as the inclusion of metadata, are, I believe, fundamental 
prerequisites for any substantial or critical technical document that has a 
long life. Structured FM+SGML documents facilitate:

+ Information repurposing and re-use.

+ Information management.

+ Information retrieval.

+ True single-sourcing, including the ability to easily output well-formed 
and correctly formatted and/or valid HTML, XML, SGML, and their derivatives.

+ Conversion to another DTP format--an essential requirement for assured 
preservation of legacy information in the event that FrameMaker disappears, 
your company decides to use a new DTP that is superior to FrameMaker, or 
you are required to deliver documents electronically in a non-FrameMaker 
format.

+ Eventually, all of a company's critical documents will have to be 
structured so that they can be parsed into their constituent structural 
elements for direct storage in a database repository of some sort. The 
longer you stick with unstructured documents, the more intractable your 
problem will become when your company adopts this approach.

So, those of you who think there is no need now to seriously consider 
changing over to a structured document approach are almost certainly 
mistaken. Even if you're not willing to consider long-term requirements, 
using FM+SGML to create structured documents now will eliminate all your 
current problems with trying to enforce style guides and formatting 
consistency. At the same time you'll improve authoring productivity and 
reduce quality assurance costs. It has been demonstrated many times that 
the return on investment by converting to a structured document approach is 
often high enough to justify the decision even without considering 
long-term needs.

At 04:57 PM 10/20/01 +0200, Thomas Michanek wrote:
>First of all, you should realize that there are 3 different situations:
>a) You apply a character tag, but no character overrides to the text.
>b) You apply a character tag *and* a character override to the text.
>c) You apply a manual character override without using any character tag.
>
>A special case of b) above is when you apply a character tag Alpha to a word,
>and then apply another character tag Beta to the same word. Since FrameMaker
>can only store a single tag name for a character formatting, this is treated
>as a character override. The last applied tag name (Beta) is stored, and the
>other tag's formatting is treated as an override. You get the exact same
>result if you apply a character override manually to that tag. (You can verify
>this by saving the file to MIF and look at how the formatting is stored.)
>
>Your statement 2) above isn't entirely correct: changes in character tag
>definitions are imported and applied correctly. However, as you state,
>character overrides are not removed in the extent you would expect. This
>is because an override to a character tag is defined in a limited way.
>You can see this in the way the asterisk indicator in the status bar for tags
>works for character tags. If you apply a manual character override to a word
>tagged with a character tag, no asterisk may appear, even though you would
>consider this an override. It's only when you apply character formatting that
>"contradicts" the tag's definition that an asterisk appear. For instance, if
>the tag defines Weight as "As is" and you later apply Bold manually, this is
>*not* considered an override to the tag. If, however, the tag defined Weight
>as "Regular", it would be considered a tag override (and an asterisk appear).
>
>Regardless if you understood the above or not :-)
>there is no functionality in standard FM for removing character overrides 
>only.
>You can probably find a FrameScript or a plug-in that does it for you, or you
>could run some editing script on the MIF file. I can help you with such a
>script, *if* you happen to have access to UNIX. Otherwise, I seem to recall a
>utility called MIFbrowse that someone familiar with MIF has made ;-)

====================
| 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.   **