More About the Graphic Conversion Utility

[Dan Emory <danemory@xxxxxxxxxxxx>]

I will send to anyone who requests it a 15KB PDF file containing the
commented EDD and the read/write rules for the FM+SGML Graphic Conversion
Utility, as described below and in my earlier post on this subject.
*************************************************************
In my earlier post, I did not fully discuss all the advantages of exporting
graphics to the MIF format, and I made some mis-statements that were
unnecessarily restrictive. Here are some amplifications that extoll the many
virtues of exporting all graphics to the MIF format so that they can then be
imported by reference or copy into FrameMaker documents as text insets
rather than as graphics (in particular, read items 7 and 8 below, which show
how this approach can solve the most nagging problems about graphics):

1. The saved MIF graphic file produced by my Graphic Conversion Utility is a
structured document that contains the top-level Graphic wrapper element and
its child graphic element, in which the graphic is contained within an
anchored frame.

2. Once it is saved as MIF as described in 1 above, you can open it in
FM+SGML (it will open as a structured document), and then save it out as a
structured document in the FM+SGML native format. Or, you can choose Remove
Structure from Document to remove the structure, and then save it in the
FrameMaker native format as an unstructured document. Consequently, the same
graphic can be used in both structured and unstructured documents.

3. If the graphic file produced in 1 and 2 above is saved as a structured
FM+SGML document, it can be imported by reference or copy as a structured
text inset into any FM+SGML structured document. If saved in 2 above as an
unstructured FrameMaker document, it can be imported by reference or copy as
an unstructured text inset into any FrameMaker unstructured document.

4. If the graphic in the graphic file produced in 1 and 2 above is imported
by reference from an external graphic file, the native FM or FM+SGML file
produced in 2 above will be updated each time the external graphic is
updated. Consequently, all documents in which the graphic file was imported
by reference as a text inset will also be updated. If, in the graphic file
produced in 1 and 2 above, you want to overlay the imported graphic with
callouts or other changes, you can first send the imported graphic to the
back, then use the FrameMaker drawing tool to add leaders, callouts, etc. on
top of it. These additions will be reflected in any FM or FM+SGML document
in which the graphic file was imported by reference as a text inset.

5. If the graphic in the graphic file produced in 1 and 2 above is in the
native FrameMaker graphic format (e.g., one created with the FrameMaker
drawing tool), you can open the graphic file and edit the graphic. These
changes will be reflected in any FM or FM+SGML document in which the graphic
file was imported by reference as a text inset.

6. Since the graphic in the graphic file produced in 1 and 2 above includes
the anchored frame as well as the graphic, and since both the graphic and
the anchored frame in the graphic file can be appropriately increased or
reduced in size as necessary for publication, authors who import it as a
text inset rather than as a graphic no longer have to be concerned about
resizing either the graphic or the anchored frame. It is always the correct
size. If several sizes of the graphic are needed, the graphic file can be
cloned to a different graphic file for each size variation.

7. A whole library of such graphics for a writing project, all created in
the manner described in 1 and 2 above, could be combined into a one or more
structured or unstructured FrameMaker master text inset files, where each
graphic is placed in a separate text flow, each of which has a suitable
descriptive name. The text inset the author wants to insert is then
determined not by selecting a graphic filename, but by selecting, in the
Import Text Flow by Reference dialog box, the text flow with the applicable
descriptive name. This eliminates the nagging uncertainties about whether
authors are specifying the correct (or latest) version of each graphic.

8. The method described in item 7 above is the ultimate payoff for saving
all graphics in the MIF format. This approach can improve and simplify
verification activities relating to graphics, because all of them are
imported by reference as text insets from the master text inset file(s),
which is/are under tight configuration control. That is, all
editing/updating of graphics is performed in the master text inset file(s),
not in the documents that use them.

9. In the case of FM+SGML structured documents there is one hitch associated
with using text insets for graphics, namely that FM+SGML cannot export the
individual text insets as SGML fragment files that can be referenced as
external entities. Instead, it exports them as full SGML document instances
with document type and entity declarations. To get around this problem, all
imported text insets must be converted to text before each export to SGML is
performed. This will convert the graphic text insets from entities to
ordinary graphics, and entity declarations for each graphic will then be
produced in the resulting SGML document instance. After the export to SGML
is accomplished, reverting to the last saved version of the document will
restore the graphics to text insets. This is not an ideal solution, but it
works.    


     ____________________
     | 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


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **