Re: Problems with FM+SGML and saving graphics in SGML files

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 09:16 PM 10/13/99 +0200, Erik Wiersma wrote:
>Hello,
>
>I am relatively new to this list. I am using FM+SGML 5.5.2. on WINNT when i
>have a sgml file with a graphic linked in it. I use the fileref property to
>describe the filelocation. While reading it in FM finds the graphic and
>displays it well. When i make some changes in FM and save the file in SGML,
>the fileref entity isn't any more there and the entityref is filled with
>graphic1. When i read it back you understand FM can't find the grapichs
>anymore. I didn't change anything on the read/write rules and I am using the
>docbook DTD.
===================================================================
First of all, the DocBook attribute names "Fileref" and "Entityref" do not
correspond to the default attribute names "file" and "entity", consequently,
read/write rules for these attributes must be provided so that FM+SGML knows
that they are to be associated with the file and entity properties. Thus,
the DocBook read/write rule for the graphic element you describe above is:

element "Graphic"
  {
    is fm graphic element;
    attribute "Fileref" is fm property file;
    attribute "Entityref"
      {
        is fm property entity;
        is fm attribute;
      }
  }
Page 273 of the FM+SGML Developer's Guide, under "Entity and File
Attributes," states that:
        "On import, if the element has no value in the entity attribute, the 
        value of the file attribute is used." (where "entity" and "file" are
        the default names of the two attributes).

However, page 273 also states that:
        "If the SGML element has an entity attribute defined, then on export
        FM+SGML writes a value in the entity attribute in SGML....If the SGML
        element has no entity attribute, and it has a file attribute, the
        software (on export) writes a value for the file attribute."

Consequently, if both a file and an entity attribute are declared for the
graphic element, and if (as is the case in the read/write rules above) both
attributes are known to FM+SGML, then FM+SGML will always opt to write a
value in the entity attribute on export, and will also write a declaration
for that entity in the SGML document instance's internal DTD subset, even
though the original SGML document specified the graphic file location to be
the Fileref attribute.

This is what is happening to you. Since the resulting entity declaration for
the entity "graphic1" specifies only the filename and not the absolute path,
and since you have probably not added the needed entity search paths for the
graphics to the DocBook application definition, FM+SGML cannot find the
graphic on import, since it does not know in which directories it should
look for it. 

Try doing this:

Change the read/write rule for the Graphic element to be as follows:

element "Graphic"
  {
    is fm graphic element;
    attribute "Fileref" is fm property file;
  }
Now, since Entityref does not appear in the read/write rule, FM+SGML has no
way of knowing that Entityref equates to the fm property named "entity",
thus it is forced to write out the filelocation in the Fileref attribute.

The problem with this solution, of course, is that, if you sometimes use the
Entityref attribute to specify a graphic entity, FrameMaker cannot recognize
the fact that Entityref equates to the entity property, and thus no graphic
will be imported.

However, it is always better to use the Entityref attribute anyway, because
then the locations of the graphic files are not platform dependent. 

     ====================
     | 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.   **