Re: Graphic Entities in FM+SGML 5.5

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 07:18 AM 3/25/99 -0500, Janice McConnell wrote:
>Dan,
>
>The writing of absolute paths in entity declarations and the
>"entity name is" rule not using the value of an fm attribute
>are two different issues. I logged 2 bugs for you during the
>beta cycle. Both were marked fixed, as I reported to you at
>the time. How entities are handled was changed considerably
>in version 5.5.x. This was in response to customer requests
>to have entites round-trip through FM+SGML.

>As you are aware,
>in version 5.1.x, general text entities are expanded on
>import and the entity information is not retained. In version
>5.5.x, entity references from the SGML import are written back on export.
========================================================
But graphic entities did round-trip through FM+SGML V5.1.1
We aren't talking about text entities, we're talking about
graphic entities. The "entity name is" rule that is the issue here
does not even pertain to text entities.
===========================================================
>The "entity name is" rule itself has not been changed.
>However, the dual mapping of the entity attribute to a fm
>attribute as well as an fm property is no longer allowed.
>Thus, it is not possible to assign an entity name through the
>use of an fm entity. Once a file is associated with an entity
>name, that association is retained - whether the association
>came from an SGML import or the creation of a FM+SGML
>document which is then exported to SGML.
============================================================
So, now tell me what happens in the case of a graphic created
with FM's drawing tools, or a graphic with multiple facets. We want to
preserve (in the FM+SGML doc) these graphic types in their original form so
that they can still be changed/edited. But on export to SGML, they must be
written
out in a non-editable (in FM+SGML), single-facet format (e.g., CGM).

Usually, the graphic types described above must be written out each 
time the doc is exported to SGML, because they are changeable within FM+SGML.
Lets say the graphic element is named GRPH. The first time the doc is
exported from V5.5.x, the assigned entity name for such a graphic is, let's
say, GRPH01, and the assigned file name is GRPH01.CGM. Now, a week later I
have modified the document in FM+SGML V5.5.x, and need to export it again to
SGML. The graphic, since it may have changed, must be written out a second time.

Will that same graphic, when it is written out the second time:

1. Overwrite the old version in file GRPH01.CGM?

        OR

2. Be written out with new entity and file names (e.g., GRPH102, and
GRPH102.CGM), leaving file GRPH01.CGM behind as a worthless artifact?

If it's 1 above, then things will work out, although authors have been
deprived of the ability (which we had in V5.1.1) to give each graphic
entity a descriptive name.

If it's 2 above (which I'm almost certain it is), then Adobe has made a
monster goof by depriving authors of the ability to name the
entity/filename, by specifying the value of the entity attribute. The result
of this goof is that, every time a non-imported graphic is written out, it
gets a new filename, leaving behind an accumulation of worthless artifact
files, and no way do distinguish the artifacts from the non-artifacts.
===================================================================
>The author can name his entities by adding entity
>declarations to the DTD before exporting to SGML.
=============================================================
That's usually not a viable option. The mere fact that you offer it as the
only alternative solution is indicative of the magnitude of the goof that
Adobe has made in V5.5.x
=============================================================
FM+SGML
>creates entity names only for files that do not yet have
>entity names associated with them through an entity
>declaration.
============================================================
That's all of them when the doc is originated in 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.   **