FM+SGML Enhancement Request No. 2

[Dan Emory <danemory@xxxxxxxxxxxx>]

EXPORTING GRAPHICS TO SGML
OVERVIEW: There are at least four types of graphics in FM+SGML structured
docs that must be written out on export to SGML:
	a. Native FrameMaker graphics
	b. Multi-faceted graphics (e.g., a screenshot overlayed
	   with callouts created with the FM drawing tool
	c. Graphics that are imported by copy or reference
	   which are in a format that is incompatible with
	   SGML usage, and must be written out in an
	   SGML-compatiblecompatible format.
	d. Equations in the native FM format.
1. In FM+SGML V5.1.x, the read/write rules allowed the entity attribute in
graphic and equation containers to be used to specify the unique,
descriptive name to be assigned to such graphics and equations when they
were written out on export. For example:

element "Graphic" {
	is fm graphic element "Graphic";
	attribute "entity" {
		is fm property "entity";
		is fm attribute;
}
	writer {
		facet "xxx" do not export;
		facet yyy export to file "$(entity).tif as "TIFF"
		anchored frame export to file "$(entity).cgm" as "CGM";
}}

For graphics that were written out on export to SGML, the above read/write
rules caused $(entity) to evaluate to the value of the entity attribute in
the graphic or equation element.  

2. This approach allowed authors to easily specify the entity name assigned
to each graphic (both those that were written out on export and those that
were not) by typing in the name into the entity attribute of each graphic
element. On export to SGML, this resulted in the following actions:
	a. The author-specified entity name was used in the entity
	   declaration written in the SGML document instance's
	   internal DTD subset.
	b. For graphics that were written out on export, the
	   stemname  of the resulting graphic file was the
           same as the entity  name.
	c. The assigned entity name was written into the entity
	   attribute of  each graphic element in the SGML 
           document instance.
3. Authors could also correlate each graphic with its assigned entity name
by looking at the entity attribute values  of graphic elements in the
structure view. Each time an FM+SGML document was exported to SGML, graphics
that were written out on export were saved under the same filename,
overwriting the previous version.

4. Alternatively, if  the entity attribute of a graphic element was left
empty, then, on export to SGML, FM+SGML assigned an unique entity name by
using the name of the graphic element, followed by an unique number (e.g.,
Graphic09). In this case, if the graphic was written out on export, the
resulting graphic file's stemname was the same as the entity name. However,
when this method was used for graphics that were written out on export, they
received a new entity name and a new filename each time the FM+SGML document
was exported to SGML. Consequently, this left in the graphic folder the
artifact graphic files from previous export operations, and authors had no
viable way of determing which files were artifacts, and which were the
latest versions, since the filenames were not descriptive.

THE PROBLEM: In FM+SGML V5.5.x, the entity name is only an FM+SGML property,
not an attribute. Consequently, the EDD cannot specify an entity attribute
for a graphic element. That is, the entity name is no longer connected to an
entity attribute in an FM+SGML graphic element. Instead, the entity name is
mapped to an entity property that is not available for edit or viewing by
the author, and instead is created by the software in the manner described
in paragraph 4 under OVERVIEW. Also, since the assigned entity name is not
available as an attribute value, authors can no longer determine the entity
name associated with each graphic, even when an SGML document instance is
imported into FM+SGML.

As explained by Janice McConnell of Adobe, the new approach is only workable
for:
	". . .authors who are importing graphics from a common
	pool" where all graphics in the common pool are declared in the DTD before
FM+SGML docs are exported to SGML.

She also added that:
	"Most of our customers appear to create and edit their
	graphics using a graphics application rather than
	FM+SGML's drawing tools."

It should also be noted that any structured documents created using the
method described in paragraphs 1 thru 3 of OVERVIEW cannot successfully be
converted to V5.5.x and then exported to SGML, because the entity attribute
in graphic and equation elements no longer maps to the entity name.

THE PROPOSED SOLUTION: Restore, in the next FM+SGML release, the mapping of
entity attributes in graphic and equation elements to the entity name, as it
was described in paragraphs 1 thru 3 under OVERVIEW.
     ====================
     | 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.   **