Text Inset Bug in FM+SGML 6.0 and 5.5

[Dan Emory <danemory@xxxxxxxxxxxx>]

Below is an excerpt from the FM+SGML 6.0 Developer's Guide
=========================================
Translating Entities and Processing Instructions, pages 238 & 239 of 
Developer's Guide
Translating SDATA entities as FrameMaker+SGML text insets
You may want to translate some SGML SDATA entities to text insets in the 
resulting
document.Note that the file you use for such a text inset must be valid 
SDATA In other
words, the source file must not be an SGML file.

The source file can be of any document type that FrameMaker+SGML can filter
automatically. Typically,such files will be FrameMaker+SGML documents or 
text files, although you can use files created by other word processing 
systems. If the source file is
a FrameMaker+SGML document,a text inset is always the entire contents of a 
flow.
If the source of the text inset is a structured flow, the document that is 
importing it will not
be valid if the flow has a highest-level element. There is one exception 
however, for
structured flows that have SGMLFragmentas the highest-level element.  An 
SGML fragment
is an SGML instance that contains neither an SGML declaration nor a DTD 
subset.Opening
an SGML fragment in FrameMaker+SGML generates a structured document with a 
highest-
level element named SGMLFragment When you import such a structured flow as 
a text
inset, FrameMaker+SGML automatically unwraps all the children of the 
SGMLFragment
element so the document that contains the text inset can be valid.
============================================
Adie Berg brought the anomaly being described here to my attention. Berg 
creates separate FM+SGML fragment files in which element SGMLFragment is 
used, as described above, to wrap structured text that is to be used 
as  text insets that are imported by reference into structured target 
documents. When such an FM+SGML fragment is imported into a target document 
as a text inset, FM+SGML behaves as advertised. Namely, it unwraps all the 
children of SGMLFragment. However, this action produces the following 
anomalous result:

Even though the unwrapped children of SGMLFragment are valid at the text 
inset insertion point, the importation of the text inset adds an empty 
paragraph to the end of the text inset. The formatting of this empty 
paragraph is the same as the formatting of the text paragraph that precedes 
the text inset. For instance, suppose such a text insed is inserted 
immediately after an autonumbered Title element. In this case, FM+SGML 
produces:
=========================
1. TITLE TEXT in a Title element
Text of the text inset. imported by reference from the fragment file.
2.
==========================
The empty autonumbered line that begins with the number 2 is added to the 
text inset, even though it was not part of the original fragment, and no 
empty line was included at the end of that fragment. This added empty line 
with the spurious autonumber has the same paragraph formatting as the 
"real" Title element that precedes the text inset, thus the autonumber gets 
incrmented.

I tried adding element SGMLFragment to the EDD (structure rule is <ANY>), 
and made this element valid at the highest level. I then imported the 
element definitions from the modified EDD into the target document, then 
re-imported the text inset into the target document. FM+SGML still unwraps 
the SGMLFragment element, and still produces the same anomalous result. In 
other words, FM+SGML still unwraps SGMLFragment, producing the same 
anomalous result, even though it is now a valid element in the target document.

Next, in the EDD, I changed the name of element SGMLFragment to 
FragWrapper, re-imported the EDD's element definitions into both the 
fragment file and the target document, and, in the fragment file, unwrapped 
element SGMLFragment, and re-wrapped the text inset text elements with the 
new element, FragWrapper. This time, when I imported the text inset, the 
anomalous behavior was eliminated (i.e., no extra empty line was added to 
the text inset, and the FragWrapper element was not unwrapped. Clearly, 
therefore, the anomalous FM+SGML behavior only occurs when a either a 
structured FM+SGML fragment or a structured SDATA entity having 
SGMLFragment as the highest-level element is imported as a text inset into 
an FM+SGML document.

 From the foregoing, I conclude that the behavior described on pages 
238-239 of the FM+SGML 6.0 Developer's Guide is not as advertised, and the 
SGMLFragment element cannot be used successfully for wrapping FM+SGML text 
insets, or for wrapping structured SDATA entities that are referenced in 
SGML instances which are being imported into FM+SGML

This is a bug. The bug exists in versions 6.0 and 5.5 of FM+SGML..

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