[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: Adrie Berg <adrie.berg@xxxxxxxxxxx>, framers@xxxxxxxxx, "FrameSGML List" <FrameSGML@xxxxxxxxxxx>
Subject: Re: Import by reference question
From: Dan Emory <danemory@xxxxxxxxxxxx>
Date: Mon, 04 Dec 2000 08:44:39 -0800
In-Reply-To: <5.0.2.1.0.20001204142207.009eeb10@mail.euronet.nl>
Sender: owner-framers@xxxxxxxxx
At 03:28 PM 12/4/00 +0100, Adrie Berg wrote: >Hello, > >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. **