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