[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Import by reference question

At 03:28 PM 12/4/00 +0100, Adrie Berg wrote:
>I import a lot of documents by reference. The imported documents are all 
>framemaker files (.fm) with embedded SGML structure and a few 
>paragraph-styles in it. The problem occurs at the bottom of the imported 
>fragment. The paragraphstyle of the line right below the imported fragment 
>has the same paragraph style of the first line in the imported fragment.
>So if the fragment I import starts with a heading1 and ends with a normal 
>body style, then at the end of the imported part there will be a heading1 
>style appearing. This also displays the standard heading1 numbering and 
>other (font)properties. This seems to happen when my imported documents 
>ends with an empty line.
>The problem in this case is that the files I import are files with an SGML 
>structure and the empty line at the end is somehow required. I would like 
>to know how I can override this behaviour and not have the (wrong) 
>paragraph styles at the end of an imported fragment. And help is appreciated.
>I use: FrameMaker+SGML 5.5.6 on Sun and FrameMaker+SGML 5.5.6 on 
>Windows98. Both systems have the same behaviour.
The problem can only be solved by placing the entire text inset (in the 
FM+SGML source file) in a wrapper element. This separates the text inset 
from the text that follows, and prevents the empty line (the empty line 
itself must be contained in an element that is part of the SGML structure) 
from affecting the formatting of the text that follows the text inset. Take 
note also that a single FM+SGML source document can contain many separate 
text insets, where each such text inset is contained in a separate, 
descriptively named text flow.

FIRST, I'm not sure what you meant by "embedded SGML structure" in the 
source document. To be valid, the source document must have, at the 
beginning of the text flow containing the text inset, a container element 
that is valid at the highest level. This container element must be the 
parent of all elements that are inside the text flow. I use an element 
named "FragmentWrapper" for this purpose.

SECOND, at any point in the target FM+SGML document where you intend to 
insert a text inset, element FragmentWrapper must be a valid element. That 
is, the structure rule for the parent element of FragmentWrapper in the 
target document must either include FragmentWrapper, or it must be 
specified as an inclusion in the parent element or one of its antecedants. 
What I've done to solve this problem is to create an element named 
InsetWrapper for this purpose, whose structure rule includes 
FragmentWrapper, as well as any additional top-level elements that may be 
used as wrappers for other types of text insets (e.g., text which you want 
to runin on the same line as the text that follows the text inset). The 
InsetWrapper element includes CDATA attributes that identify the FrameMaker 
source file, the name of the text flow in the source file which contains 
the text inset, and the entity name assigned to that text inset in the 
read/write rules. These attributes are for informational purposes only 
(i.e., they have no effect on the export/import process).

THIRD, in the read/write rules file (either the main read/write rules file, 
or  in a supplemental rules file that is included (by means of an Include 
statement in the main read/write rules file), I specify a read/write rule 
of the following form for each text inset in my text inset library:

entity "entityname" {
         is fm text inset "sourcefilename"
                 in body flow "flowname";
         retain source document formatting;

FOURTH, in the DTD, I declare an external parameter entity named txinsets. 
In that external paramerter entity file (I name it txinsets.ent),  I 
declare each text inset for which a rule exists in the read/write rules of 
the following form:

<! ENTITY entityname SDATA "[entityname]" >

The result of these steps is that, on export to SGML, the text inset is 
replaced by an entity reference, and, when the resulting SGML document 
instance is
imported back into FM+SGML, the entity reference is replaced by the 
read/write-rule-specified text inset. If you do not use this approach, the 
entire text inset is included in the exported SGML, and, when you import 
the SGML instance back into FM+SGML, the FM text inset is not used, and 
thus, if the text inset was changed, those changes are not reflected in the 
imported document, and the imported content of the text inset in the SGML 
instance will no longer reflect the formatting of the original text inset.

The problem here, of course, is how to create the SDATA entities that are 
referenced in the SGML document instance so that the SGML document instance 
will include the referenced SDATA entities when it is viewed in an SGML 
browser. SDATA entities cannot contain an internal DTD subset. But if you 
attempt to export an individual text inset from the FM+SGML source file, an 
internal DTD subset is created. You could edit out the internal DTD subset 
to create a valid SDATA entity, but you must be sure that all entities 
referenced within the SDATA file are declared in the DTD. Now, if you do 
all of the above, the external parameter entity file txinsets.ent will 
properly replace the entity references with the corresponding SDATA 
entities when the document is viewed in the SGML browser, and will replace 
those entity references with the FM+SGML text insets on import to 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
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.   **