Re: Graphic Entities in FM+SGML 5.5

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 12:54 PM 3/26/99 -0500, Janice McConnell wrote:
>>At 11:36 AM 3/25/99 -0700, Dan Emory wrote:
>>-------------------------------Snip
>>   ========================================================
>>   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.
>++++++++++++++++++++++++++++++++++++
>>--------------------Snip
>++++++++++++++++++++++++++++++++++++++++++++++++++++++
>If graphics are created in a FM+SGML document or if imported
>graphics are edited (or have multiple facets), 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.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
===============================================================
Not only will the old versions of such graphics not be overwritten,
they will remain as irrelevant artifacts. Since, in V5.5.x, entity
and file names are non-descriptive (e.g., base013.cgm), the
user has no viable way to distinguish the artifact files from
the ones that are still current. All of this was avoidable in
V5.1.x by allowing the author to specify a descriptive entity
name, in which case, graphics and equation preserved the
same entity and file names when written out on export to SGML,
and the old versions were overwritten. Adobe has taken that option
out of V5.5.x.

Your implied workaround (choosing a different directory each
time an FM+SGML doc is exported to SGML) is cumbersome and infeasible,
because it does not overwrite the previous SGML version, and does
not address the problem of the imported-by reference graphics
(not written out on export) which are still in the old directory,
and thus their pathnames are invalid.
===================================================
>>   Declaring graphic and equation entities in the DTD
>>   is 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.
>+++++++++++++++++++++++++++++++++++++++++++++++
=================================================================
You neglect to mention equations in Frame's native format, which
must always be written out on export to SGML, and thus cannot be
part of a common pool.
================================================================
>>----------------------Snip
>++++++++++++++++++++++++++++++++++++++++++++++++
>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.
=========================================================
So, here's what we have:

CASE 1. In V5.1.x, authors had the OPTION
to specify the value of the entity attribute for graphics and
equations, and the OPTION to specify the read/write rule
as follows:

element "Graphic" {
	is fm graphic element "Graphic";
	attribute "file" is fm property file;
	attribute "entity" {
		is fm property entity;
		is fm attribute;
}}

In this case, $(entity) in the read/write rule for exporting a
graphic or equation evaluates to the value of the entity attribute,
and the graphic is written out with the filename entity.xxx, where xxx
is the name of the graphic format type. This allowed users TO KNOW      
IN ADVANCE the entity and file names that would be associated with
each non-imported graphics, as well as all equations, that is written out on
export to SGML. If the entity attribute is left empty, then CASE 2
below applies.
 
CASE 2. Alternatively, in V5.1.x,developers had the OPTION to specify
in the EDD that the entity attribute was Read Only, preventing authors
from entering a value. If that option is chosen, then $(entity) in the
read/write rule for exporting a graphic or equation evaluates to a
unique name whose base name is the name of the graphic element (e.g.,
Graphic01), and the graphic is written out to a file named
Graphic01.xxx, where xxx is the name of the graphic format type.

CASE 3. In either CASE 1 or CASE 2 in V5.1.x, when an SGML document
instance containing graphics or equations was imported into FM+SGML,
the entity attribute in the graphic element contained the name of
the graphic entity, which could be seen in the structure view, or by
opening the Attributes dialog. Users could also search on the entity
attribute.

CASE 4. In V5.5.x, Adobe hs taken away the option to use CASE 1, and has
deprived  authors of the capability (as described in CASE 3)
to identify the entity name associated with each graphic or equation in a
document. To replace CASE 1, you state that users must write an API.

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

What you are really saying here is that native FM graphics and
equations, both of which must always be written out on export to SGML,
are incompatible with the V5.5.x implementation. They were not
incompatible with the V5.1.1 implementation, thus V5.5.x is
regressive.
---------------------------------------------------------
There was absolutely no plausible reason in V5.5.x for depriving users
of the ability to employ CASE 1 above as an OPTION. The use of this option
(to export native graphics, multi-faceted graphics, and equations,
as well as for converting, on export, imported-by-reference graphics
to formats that are more SGML-compatible) does not conflict in any way
with the new "feature" in V5.5.x of preserving (on a reference page),
on import to FM+SGML, the existing entity declarations in an SGML
document instance. Despite this fact, Adobe has removed the CASE 1
feature, which requires, you say, users who need it to develop an API.

The least Adobe should do to correct this monstrous goof is to offer such
an API, free of charge, to anyone who needs it, and to restore the
CASE 1 capability in the next release. Otherwise, FM+SGML has a fatal flaw
for users who originate structured documents in FM+SGML who also:

1. Do not use a "common pool" of graphics whose entity declarations
   are included in the DTD.

2. Utilize native FM graphics, multi-faceted graphics, or equations
   in their documents, which must be written out each time an
   FM+SGML doc is exported to SGML.

3. Utilize imported-by-reference graphics which must be written out
   in an SGML-compatible format on export to 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.   **