Re: Graphic Entities in FM+SGML 5.5

[Janice McConnell <jym@xxxxxxxxx>]

At 11:36 AM 3/25/99 -0700, Dan Emory wrote:
   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.
   ===========================================================
++++++++++++++++++++++++++++++++++++
Sorry about that, Dan. I didn't mean to confuse the issue - I
was just throwing in more background about how entity
handling changed from 5.1.x to 5.5.x.
++++++++++++++++++++++++++++++++++++
   >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.
   ===================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++
If graphics are created in a FM+SGML document or if imported
graphics are edited, then the software will create new
graphics and entity declarations when the document is
exported to SGML. If the graphic, created by a previous
export to SGML, is in the same directory as the new SGML
document being created, and the entity base name hasn't been
changed, the graphic for the previous SGML document will not
be overwritten. The software checks for duplicate graphic
names in that directory.
++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
   >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
   =============================================================
+++++++++++++++++++++++++++++++++++++++++++++++
It is a viable option for authors who are importing graphics
from a common pool. Most of our customers appear to create
and edit their graphics using a graphics application rather
than FM+SGML's drawing tools.
+++++++++++++++++++++++++++++++++++++++++++++++
   >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.
   ==========================================================
++++++++++++++++++++++++++++++++++++++++++++++++
It is all of them ONLY if the graphics are not imported by
reference from a pool of graphics for which entity
declarations have already been written. If, as you indicate,
your work-flow uses frame-drawn graphics or imported graphics
which are edited in FM+SGML, then you should consider writing
an API client to customize the handling of entities to fit
your work-flow.
        ____________________
        | 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.   **