🚀 go-pugleaf

References:  Message-ID: <1992Aug4.205316.17343@ornl.gov>

Jim Mason writes:

> Lofton Henderson and Geourge Carson, posed the same quesion to me,
> wondering whether SGML could not somehow be used to give some structure
> to CGM so that a document database manager could also search graphics
> files. This is a question that should also be brought up with the
> STEP/PDES folks in TC184, since they intend to create large databases
> that include, among other things, text and graphics that will need
> interconnection. HyTime is intended to manage documents that include
> data in "foreign" notations, so perhaps someone will show how it can be
> used to link into graphics without having to interpolate some of that
> dreaded "markup" into CGM.

Here is my "graphics dtd", which defines a set of architectural
forms for graphic elements and specifies processing semantics
ala the HyTime standard.  This is a rough draft that I knocked
out on a Sunday.  I am not a graphics person, so I'm sure there's
much that I overlooked, but it is at least a stab at the graphics
problem.

I see four chief advantages to having SGML-coded graphics:

1. Full hypertext linking into and out of the graphics is enabled
   using exactly the markup methods and processing used for text
   elements today (e.g., BookMaster/BookManager, etc.).  Lack of
   standard ways to encode linking in graphic formats today is a
   serious barrier to implementing what I would consider full-function
   hypermedia systems.

2. Translation of text in graphics is enabled using the same tools
   and techniques used to translate text.  IBM applies a lot of
   resource to the translation problem and lot of it keys off of
   markup, and will do more so in the future.  Translation of graphics
   is a very big problem for IBM, and will only get worse as we
   drive toward more multi-media delivery of information.  I know
   other enterprises also have translation problems.

3. The markup specifically enables re-use of graphic objects, including
   defining processing semantics for use-by-reference of object
   content.

4. Independence of graphic specification from presentation systems.
   I was initially inspired by PostScript's graphics support, which
   my markup could be easily mapped to.

One of my goals was to define an architecture that would support
the full range of presentation sophistication, from the sort
of box and line character graphics I'm capable of creating to
full-blown graphics of arbitrary complexity.  Simple graphics
could be keyed by hand, complex graphics would be generated by
real graphic authoring tools.

The main cost of processing this markup is gathering and validating
the attribute values.  Once you've got that data, the drawing part
is easy (especially if you let PostScript or CGM or some other
relatively-declarative graphic system do the work).  The other cost
is that of storing data about objects so that their specifications
and content can be re-used, but this is just a dasd/memory cost
(albeit a high one for large graphics).

Note that graphics using this markup can participate completely
in my regular SGML document so that I could, for example, allow
head references in text objects or use the same convenience
entities in text objects I use elsewhere.

Take what follows for what it is: a draft of an idea that's
unique only in that it is expressed in SGML.  If this idea pans
out, it might find its way into some future document architectures.
If it's a bad idea, it dies on the vine.  Part of this exercise for
me was exploring how to write architecture specifications.  One
question I would ask is "have I written it well enough that you
would be confident that your implementation actually does what I
meant for it to do?"

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709

Graphics DTD "architecture" follows:

<!--===============================================================+

    This DTD fragment defines a set of graphic elements used to
    describe graphics as declaritively as possible.  These elements
    could be used directly or could be taken as architectural forms
    mapped to from a data-specific set of elements (for example,
    data flow diagrams or flow charts).  The intent of these elements
    is to describe graphics with complete independence from any
    presentation system or method.  It is permissible for applications
    to define restrictions not defined in this definition in order
    to meet the restrictions of the presentation systems the application
    supports.  For example, a system that only supports character-based
    graphics may limit direction values to multiples of 90 degrees
    and may not allow the creation of polygons.  However, applications
    must support the required elements and must support any optional
    elements they declare support for, except when the processing
    system directly supports multiple output forms.  In that case, the
    application can declare support for the most-functional output
    format, even if other supported output forms cannot support the
    same set of optional features.  The application must clearly document
    the restrictions imposed by constrained output formats and must
    issue warnings when unsupported elements are used when creating
    output for constrained output formats.  For example, an application
    may support both PostScript devices and character-based displays.
    It may therefore declare support for all graphic objects, document
    restrictions when processing for character-based displays, and
    issue warnings when unsupported objects are used and the output
    device is the character display.  It is up to the application to
    decide how to approximate the presentation of supported objects
    on constrained devices.  At a minium, a rectangular area bounding
    the object must be presented.

    This definition defines a set of elements that represent, more or
    less, architectural forms and related processing actions.

    The elements defined here are either required for conformance or
    are optional.  The required elements represent the minimum support
    needed to create simple graphics (boxes, lines, circles, and text)
    from the markup.  The optional elements, combined with the required
    elements, represent a full-function language and related set of
    processing functions for creating graphics of arbitrary complexity.

    The required elements do not include the GOBJLIB or GOBJREF elements,
    nor the CURVE, CONNECTOR, nor IMAGE, elements.  The implementation
    of these elements requires significant processing overhead,
    complex algorithms, and application-specific support systems that
    if required would make a conforming implementation prohibitively
    expensive.

    Most elements take attributes for different methods of defining
    presentation location.  When definition methods are mutually
    exclusive, the processing application must issue warning messages
    when mutually-exclusive attributes are coded.  It must not be a
    terminal error to specify mutually exclusive attributes.  Processing
    applicatons must define undertandable algorithms for resolving
    conflicts between different forms of location specification.
    It is suggested that point references be prefered over explicit
    locations.

    In the case where attribute values are not correct, it is up to
    the application to decided whether or not to consider that condition
    terminal or define appropriate default behaviors.

    Object ID uniqueness scope can be either the entire document or
    limited to the scope of the GRAPHIC element itself.  Limiting ID
    scope to GRAPHIC reduces the system overhead of graphic processing
    as object data does not need to be maintained once the graphic has
    been processed.  In addition, if object libraries are supported,
    library ID scope can be the entire document even if object ID
    scope is limited to the GRAPHIC element.  If ID uniqueness is not
    maintained for the whole document, hypertext links to objects
    within graphics must be done by qualifiying the object ID with the
    graphic ID.  GRAPHIC IDs must be unique across a document.

    Change History:

       Created 7/18/92 by W. Eliot Kimber
    +===============================================================-->
<!--================================================================+

                          Entity Declarations

  +================================================================-->
<!-- Attributes for defining hyperlinks: -->
<!ENTITY % link.at
"refid    NAME    #IMPLIED -- ID of link target    --
 docid    NAME    #IMPLIED -- ID of document containing target object --
 linkid   NAMES   #IMPLIED -- ID(s) of link description element(s)--"
>
<!-- Attributes for describing lines: -->
<!ENTITY % line.1
"points   NAMES   #IMPLIED -- IDs of points to connect --
 startpt  NAME    #IMPLIED -- ID of starting point --
 endpt    NAME    #IMPLIED -- ID of ending point   --"
>
<!ENTITY % line.2
"startX   CDATA   #IMPLIED -- X coordinate of starting point --
 startY   CDATA   #IMPLIED -- Y coordinate of starting point --
 endX     CDATA   #IMPLIED -- X coordinate of ending point --"
>
<!ENTITY % line.3
"endY     CDATA   #IMPLIED -- Y coordinate of ending point --
 length   CDATA   #IMPLIED -- length of line               --
 directn  CDATA   #IMPLIED -- 0-360.  Direction line points--"
>
<!ENTITY % line.4
"startsty CDATA   #IMPLIED -- line end style choices       --
 endsty   CDATA   #IMPLIED -- line end style choices       --"
>
<!--
<!ENTITY % line.at "%line.1 %line.2 %line.3;%line.4;%line.4;">
-->
<!-- Attributes for describing boxes: -->
<!ENTITY % box.1
"uleftpt  NAME    #IMPLIED -- ID of upper left starting point --
 ureftpt  NAME    #IMPLIED -- ID of upper right starting point --
 lleftpt  NAME    #IMPLIED -- ID of lower left starting point --"
>
<!ENTITY % box.2
"lreftpt  NAME    #IMPLIED -- ID of lower right starting point --
 ulX      CDATA   #IMPLIED -- X coordinate of upper left corner  --
 ulY      CDATA   #IMPLIED -- Y coordinate of upper left corner  --"
>
<!ENTITY % box.3
"urX      CDATA   #IMPLIED -- X coordinate of upper right corner --
 urY      CDATA   #IMPLIED -- Y coordinate of upper right corner --
 llX      CDATA   #IMPLIED -- X coordinate of lower left corner  --"
>
<!ENTITY % box.4
"llY      CDATA   #IMPLIED -- Y coordinate of lower left corner  --
 lrX      CDATA   #IMPLIED -- X coordinate of lower right corner --
 lrY      CDATA   #IMPLIED -- Y coordinate of lower right corner --"
>
<!ENTITY % box.5
"WIDTH    CDATA   #IMPLIED -- width of box in units              --
 DEPTH    CDATA   #IMPLIED -- depth of box in units              --"
>
<!--
<!ENTITY % box.at "%box.1 %box.2 %box.3 %box.4;%box.5;box.5;">
-->
<!-- Attributes for describing circles: -->
<!ENTITY % cir.1
"centerpt NAME    #IMPLIED -- point ID of point to be center     --
 centerX  CDATA   #IMPLIED -- X coordinate of center point       --
 centerY  CDATA   #IMPLIED -- Y coordinate of center point       --"
>
<!ENTITY % cir.2
"centerp2 NAME    #IMPLIED -- point ID second point of ellipse   --
 centerX2 CDATA   #IMPLIED -- X coordinate of second ellipse point--
 centerY2 CDATA   #IMPLIED -- Y coordinate of second ellipse point--"
>
<!ENTITY % cir.3
"radiuspt NAME    #IMPLIED -- point ID of point to define edge   --
 radiusX  CDATA   #IMPLIED -- X coordinate of radius point       --
 radiusY  CDATA   #IMPLIED -- X coordinate of radius point       --"
>
<!ENTITY % cir.4
"length   CDATA   #IMPLIED -- length of radius                   --
 directn  CDATA   #IMPLIED -- 0-360.  Direction redius points    --"
>
<!--
<!ENTITY % cir.at "%cir.1;%cir.2;%cir.3;%cir.4;%cir.4;">
-->
<!-- Attributes for describing object style: -->
<!ENTITY % sty.1
"rotation CDATA   #IMPLIED -- -360 to 360 degrees                --
 linesty  CDATA   #IMPLIED -- (solid|dashed|invisible)           --
 linewght CDATA   #IMPLIED -- weight name or unit value (may be
 fractional --"
>
<!ENTITY % sty.2
"fill     CDATA   #IMPLIED -- fill (shade) percentage 0 to 100%  --
 textsty  CDATA   #IMPLIED -- Text style of contained text       --"
>
<!ENTITY % sty.3
"linecol  CDATA   #IMPLIED -- Color for lines                    --
 textcol  CDATA   #IMPLIED -- Color for text                     --
 fillcol  CDATA   #IMPLIED -- Color for fill                     --"
>
<!--
<!ENTITY % sty.at "%sty.1 %sty.2 %sty.3">
-->
<!-- Common content model entities: -->
<!-- Phrase elements: -->
<!ENTITY % phr.el "phrase" -- phrases within text                -->
<!-- The %phr.el; entity is intended to be replaced by application-
     specific definition specific to the application's DTD.  It
     must be defined before this definition is processed in order
     to override the definition above.
-->
<!--  Graphic objects:              -->
<!--    Supported notations:          -->
<!ENTITY % notates  "tiff" -- supported image notations --
                           -- Redefine this entity in your dtd --
                           -- to support other notations       --
>
<!ENTITY % not.def  "tiff" -- default notation                 --
                           -- Redefine this entity in your dtd --
                           -- to support other notations       --
>
<!--    Optional elements             -->
<!ENTITY % orf.obj  "|gobjref" -- If object references are not   --
                               -- supported, define this entity  --
                               -- as null in your DTD.           --
>
<!ENTITY % gobjref  SYSTEM  "GOBJREF DTD"
                               -- External entity declaration    --
                               -- for GOBJREF definition.        --
                               -- If GOBJREF is not supported,   --
                               -- define as null in your DTD.    --
>
<!ENTITY % lib.obj  "|gobjlib"
                               -- If object libraries are not    --
                               -- supported, define this entity  --
                               -- as null in your DTD.           --
                               -- GOBJREF is required by GOBJLIB.--
>
<!ENTITY % cur.el   "|curve"
                               -- If curves are not              --
                               -- supported, define this entity  --
                               -- as null in your DTD.           --
>
<!ENTITY % con.el   "|connect"
                               -- If connectors are not          --
                               -- supported, define this entity  --
                               -- as null in your DTD.           --
>
<!ENTITY % grp.obj  "point|line|box|circle|arc|text %lib.obj; %orf.obj; %cur.el; %con.el;"
>
<!--================================================================+

                          Element Declarations

  +================================================================-->
<!-- High-level Element: -->
<!ELEMENT graphic  - - (gobjlib?, ((%grp.obj;)* | region*)
                       )
-- A graphic contains regions     -->
<!ATTLIST graphic  id      NAME   #IMPLIED  -- graphic ID          --
                   Xunits  CDATA  #IMPLIED  -- width in units      --
                   Yunits  CDATA  #IMPLIED  -- depth in units      --
                   Awidth  CDATA  #IMPLIED  -- absolute width      --
                   Adepth  CDATA  #IMPLIED  -- absolute depth      --
                   directn (xaxis | yaxis | zaxis) #IMPLIED
                           -- placement direction for contained regions--
  %sty.1;%sty.2;%sty.3; -- Style attributes                    --
>
<!-- Xunits= and Yunits= define the placement grid for the graphic.
     All object unit references are relative to this grid (except
     for regions as explained under the REGION element).  Absolute
     width and depth are in real measurements (or in HyTime terms,
     the way HyTime expresses "real" measurements).  If either Awidth=
     or Adepth= is specified, the graphic is scaled proportionately
     in both directions to maintain a 1:1 aspect ratio.  If both Awidth=
     and Adepth= are specified, then the aspect ratio will be the ratio
     of Awidth:Adepth.

     Note that GRAPHIC is a special case of REGION and in all ways
     behaves like REGION except as defined above.
-->
<!-- GOBJLIB: graphic object library.  Contains objects for later
              presentation by reference.
-->
<!ELEMENT  gobjlib - - (%grp.obj;)* >
<!ATTLIST  gobjlib id      NAME   #IMPLIED  -- object ID           --
                   desc    CDATA  #IMPLIED  -- Description         --
>
<!-- Graphic object library contains graphic objects but does
     not present them.  Objects contained within an object library
     can be used by reference.  Object placement values are applied
     against the context within which they are referenced, thus it
     is the responsibility of the document author to use placement
     methods and values that will be meaningful.  The gobjref element
     can define the origion points for referenced objects, making it
     possible to use relative values for sizes and coordinates.

     Support for GOBJLIB is optional.  Support for GOBJLIB requires
     support for GOBJREF.
-->
<!-- REGION:  divides a graphic into independent prensentation areas.-->
<!ELEMENT  region  - O ( region* | (%grp.obj;)*) >
<!ATTLIST  region  id      NAME   #IMPLIED  -- region ID           --
                   directn (xaxis | yaxis | zaxis) #IMPLIED
                           -- placement direction for contained regions--
                   width   CDATA  #IMPLIED  -- region width in units --
                   depth   CDATA  #IMPLIED  -- region depth in units --
  %sty.1;%sty.2;%sty.3; -- Style attributes                    --
>
<!-- Regions are placed along the X, Y, or Z axis.
     Regions placed in the Z direction constitute independent graphic
     planes.  Objects within the same region are always joined, while
     objects in higher planes overlay objects in lower planes.  Regions
     are placed in the Z axis from lowest to highest.  Thus the first
     contained region is the lowest, the last contained region is the
     highest.  Regions on the same X or Y axis never overlap.

     Reference to points across region boundaries is always relative to
     the common unit grid for both regions.  For regions in the Z
     direction, this means that the result of using a point in one
     region for the origion of a point in the other region will result
     in both regions being presented at the same point, regardless of
     the placement grid used within each region.  In other words, using
     a point in another region says "place me over where this other point
     will be when my region is overlayed on top of its region."

     When reference is across regions not in the Z axis, the placement
     result will be as though both regions were in the Z axis.

     Width and depth define the absolute width of the region in terms
     of the containing graphic or region.  All object measurements for
     objects within the region are then relative to the region rather
     than the graphic itself.  This allows the definition within a region
     of objects that would otherwise exceed the bounds of the containing
     graphic or region.  Objects need not be placed within the boundaries
     defined by the graphic (thus, the graphic units can be thought of as
     defining the viewport into a graphic).  Making region scaling
     relative to its container ensures that all its contained objects
     will be presented, regardless of the size of the viewport.  Note that this
     may cause inappropriate scaling and result in poor presentations.
     The correct solution in this case is to adjust the container width.

     If width and depth are not coded, then the region will be
     sufficiently wide to present its contents in the units of
     the containing graphic or region.  This may result in the clipping
     of objects that fall outside the container.

     Note that objects contained within other objects are measured
     relative to the containing region, not the containing object.
     However, points can be defined relative to other points, enabling
     effective drawing relative to the points used to draw a containing
     object.
-->
<!-- GOBJECT: graphic object.  Contains other objects.               -->
<!ELEMENT  gobject - - ( %grp.obj;)* >
<!ATTLIST  gobject id      NAME   #IMPLIED  -- object ID           --
                   %link.at; -- Link attributes                    --
  %sty.1;%sty.2;%sty.3; -- Style attributes                    --
>
<!-- Graphic object serves as a container of presentation objects.
     It differs from Graphic Object Library in that the objects it
     contains are presented directly, unless the graphic object is
     itself contained within a graphic object library.


     GOBJECT enables the grouping of disparate elements into a single
     unit that can be used by reference.  It has no presentation
     effect or control.  Contained elements are otherwise independent.
     In otherwords the GOBJECT element does not define a containing
     area or origin for the contained objects.  GOBJECT contains
     an arbitrary collection of elements without regard for where they
     are placed in the area.  GOBJECT can contain object references,
     thus effectively containing objects from anywhere (either in the
     graphic or in the document depending on how the application has
     defined the object name scoping rules).

-->
<!-- POINT:  defines a point location within the region.             -->
<!ELEMENT   point  - O EMPTY  --                                     -->
<!ATTLIST   point  id       NAME   #REQUIRED -- point ID              --
                   Xpos     CDATA  #IMPLIED  -- absolute X position   --
                   Ypos     CDATA  #IMPLIED  -- absolute Y position   --
                   refpoint NAME   #IMPLIED  -- ID of point this point--
                   rXpos    CDATA  #IMPLIED  -- is positioned relative--
                   rYpos    CDATA  #IMPLIED  -- to.                   --
                   directn  CDATA  #IMPLIED  -- 0-360. Movement       --
                   distance CDATA  #IMPLIED  -- direction and distance--
                                             -- relative to refpoint. --
>
<!-- Points are anchors from which other placement and drawing is done.
     Points are either positioned absolutely within a region or relative
     to another point.  Relative position is specified as either
     relative X and relative Y, or by an angular direction and distance
     in units from the reference point.

     Points have no presentation effect.
-->
<!-- LINE: creates a line between two points or as a vector.         -->
<!ELEMENT   line   - O (label?)  -- A line segment.                   -->
<!ATTLIST   line   id       NAME   #IMPLIED  -- line ID               --
                   %link.at; -- Hyperlink attributes                  --
  %line.1;%line.2;%line.3;%line.4; -- Line attributes           --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- Lines are drawn either as vectors, using angular direction and
     length or as line segments between two coordinates.  When POINTS=
     is coded, the line is a series of line segments drawn from point
     to point in the order coded.

     Line end styles enable creation of arrows and various joints.
     Provided styles must include arrow heads and all line-to-line
     joints.  Applications are free to define the specifics of these
     elements as well as other end style options.
-->
<!-- BOX: creates a rectangular box.                                -->
<!ELEMENT   box    - O (label?, (%grp.obj;)*) -- A box                -->
<!ATTLIST   box    id       NAME   #IMPLIED  -- Box ID                --
                   %link.at; -- Hyperlink attributes                  --
 %box.1;%box.2;%box.3;%box.4;%box.5;
                             -- Box attributes                     --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- Boxes can be specified in a variety of ways.  Some combination of
     attributes must specify at least opposite corners or one corner
     and a width and depth value.  If all four corners are specified,
     they will be connected without regard to the resulting corner
     angles.  In all other cases, corners will be 90 degree angles.
     For presentation environments where all corners must be 90 degrees,
     the behavior when all four corners are explicit and would result
     in other than 90 degree angles is undefined.  It will be up to
     the presentation application to handle the situation as appropriate.

-->
<!-- CIRCLE:  creates closed circle or ellipse                      -->
<!ELEMENT   circle - O (label?, (%grp.obj;)*) -- A circle             -->
<!ATTLIST   circle id       NAME   #IMPLIED  -- circle ID             --
                   %link.at; -- Hyperlink attributes                  --
  %cir.1;%cir.2;%cir.3;%cir.4;  -- circle attributes          --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- Circles are specified as a center point plus a radius point.
     The radius point defines both the width of the circle and the
     point from which drawing is started (important only for arcs).
     If a second center point is specified, then the circle becomes
     an ellipse.

     Circles are required elements.  However, because some presentation
     systems are constrained to horizontal or vertical lines, it is
     permissible for applications to document restrictions on the use
     of circles for these constrained presentations and issue warnings
     when circles are used.  Applications must define an approximate
     presentation for circles, which at minimum is to present a bounding
     box representing the greatest extent of the circle (or arc).

-->
<!-- POLYGON:  creates closed polygon.                                -->
<!ENTITY % poly.at
"corners  NAMES  #IMPLIED  -- point IDs of each corner.               --
 edgewid  CDATA  #IMPLIED  -- width of all edges   --
 edgecnt  CDATA  #IMPLIED  -- total number of edges--"
>
<!ELEMENT   polygon - O (label?, (%grp.obj;)*) -- A closed polygon    -->
<!ATTLIST   polygon id       NAME   #IMPLIED  -- circle ID            --
                    %poly.at; -- Polygon attributes                   --
                    %link.at; -- Hyperlink attributes                 --
   %cir.1;%cir.2;%cir.3;%cir.4;  -- circle attributes         --
   %sty.1;%sty.2;%sty.3;  -- Style attributes                     --
>
<!-- Polygons are either specified as a regular polygon using the
     circle attributes plus an edge count and edge width, or by
     explicitly specifying a series of corner points.

     These two methods are mutually exclusive.  When circle specification
     is used, the circle defines the placement of the edge intersections
     (the circle bounds the polygon).  When the explicit corner method
     is used, the corner points are connected in the order specified
     in the attribute value, with the last point being connected to the
     first.

     Polygon support is required.  The rules for polygon support for
     constrained presentation environments is the same as for circles.

-->
<!-- ARC:  creates an arc.  Note that circle is a special case of arc -->
<!ELEMENT   arc    - O (label?) -- An arc                             -->
<!ATTLIST   arc    id       NAME   #IMPLIED  -- arc ID                --
                   extent   CDATA  #REQUIRED -- 0 to 360 degrees      --
                   %link.at; -- Hyperlink attributes                  --
  %cir.1;%cir.2;%cir.3;%cir.4;  -- circle attributes          --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- Arcs are specified as for circles.  For Arcs, the radius
     points define the starting location of the arc, which is then
     drawn either clockwise or counter clockwise around the center
     point.

     Arc support is required.  The rules for arc support for
     constrained presentation environments is the same as for circles.
     Note that for arcs with an extent of 90 degress or less, the
     bounding box is determined by the end points of the arc, not the
     circle of which the arc is a part.
-->
<!-- CURVE:  creates a mathematical curve.                            -->
<!ELEMENT   curve  - O (label?) -- A curve.                           -->
<!ATTLIST   curve  id       NAME   #IMPLIED  -- curve ID              --
                   %link.at; -- Hyperlink attributes                  --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
--<I have no idea how to actually specify curves, so this element is
   undefined in terms of specific attributes and processing behavior.
   WEK>
--
>
<!-- Description of CURVE

     Because of its complexity, CURVE is an optional element.
-->
<!-- IMAGE:  contains an image in an application-defined notation    -->
<!ELEMENT   image  - O (#PCDATA)-- An image                           -->
<!ATTLIST   image  id       NAME     #IMPLIED  -- image ID           --
                   %link.at; -- Hyperlink attributes                 --
                   %box.1;%box.2;%box.3;%box.4;%box.5;
                             -- Box attributes define bounding box --
                   name     ENTITY   #CONREF   -- reference to NDATA --
                   notation NOTATION (%notates;) %not.def;
                                                        -- notations --
>
<!-- IMAGE contains an image in the named notation or refers to an
     image in an external entity (which defines its own notation).
     The image notation is a function of the supporting application.

     The box attributes can be used to define the bounding box to which
     the image is clipped or scaled (if possible).  If no bounding box
     is defined, the image is bound by whatever element contains the
     image, which may be the GRAPHIC element itself.  The image is
     clipped to the shape of its container.

     Note that the image does not have to be an image in the sense of
     a raster image or bitmap.  It could, in fact, be a multimedia object
     or something else.  The IMAGE element effectively functions as a
     way to define within a graphic a region the contents of which are
     defined by the processing application or presentation system and
     not the GRAPHIC markup itself.  For example, the NDATA entity could
     be a video clip that is presented within the bounding box.  It is
     up to the processing application to provide this support.  This
     definition does not require support for any image format, and thus
     does not require support for multimedia, while it does enable it.

     IMAGE support is optional.
-->
<!-- CONNECTOR: connects to points or objects                         -->
<!ELEMENT   connect - O (label?)  -- A connector.                     -->
<!ATTLIST   connect id       NAME   #IMPLIED  -- Connector ID         --
                    startobj NAME   #IMPLIED  -- ID of starting object--
                    endobj   NAME   #IMPLIED  -- ID of ending object  --
                   %link.at; -- Hyperlink attributes                  --
  %line.1;%line.2;%line.3;%line.4; -- Line attributes           --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- Connectors connect two objects.  Connectors are different from
     lines in that they may be curved.  Connectors, by definition,
     will be placed in such a way as to not cross any objects in the
     same region, if at all possible.  The drawing of connectors is
     thus an algorithmic process.  For objects other than points,
     connectors always travel between near edges of the connected
     objects (or the nearest that will allow drawing of a valid
     connector).  It is a warning condition when a valid connector
     cannot be drawn.

     Connectors can be drawn from points or objects within one object
     to an object outside the containing object.  In this case, the
     connector starts at the edge of the object that is at the same
     hierachical level.  For example, to draw connectors between a circle
     and objects outside the circle, you could define the start object
     as the point at the center of the circle.  The actual connector
     lines would be drawn from the edge of the circle to connected
     objects, but the connector drawing algorithm will ignore the edge
     of the circle for purposes of determining best path.

     Connectors drawn from an object to an object contained within
     annother object ignore the edges of the containing object(s) for
     purposes of determining the connector path.  This allows, for
     example, to draw connectors from text objects to subobjects within
     a larger object.

     Note that containment in this case is the containment defined by
     the SGML markup, not containment defined by intersecting
     presentation points.

     Connector support is optional.
-->
<!-- TEXT:  Contains text.                                            -->
<!ELEMENT   text    - O (label?, (#PCDATA | %phr.el;)*) --            -->
<!ATTLIST   text    id       NAME   #IMPLIED  -- text ID              --
                    auto     (auto) #CONREF   -- makes an xref        --
                   %link.at; -- Hyperlink attributes                  --
  %line.1;%line.2;%line.3;%line.4; -- Line attributes           --
  %sty.1;%sty.2;%sty.3;  -- Style attributes                      --
>
<!-- The TEXT object contains text.  Line attributes are used to
     define the line along which the text is drawn.  If line
     attributes are not used, the text presentation is controlled
     by the containing element.  For example, text within a box is
     by default flowed within the box.  Text that does not fit
     within its container is truncated on the right.  Text font
     is controlled by the application-specific style functions and
     is not determined by the GRAPHIC markup.  The GRAPHIC markup
     can control the scaling of the font relative to the active
     presentation grid.
-->
<!-- LABEL:  Defines the label for an object.                         -->
<!ELEMENT   label   - O (#PCDATA | %phr.el;)*  --                     -->
<!-- The label element contains label text, which may be further
     identified by phrase elements, which may include reference
     elements, as defined in the application's DTD.

     The presentation of the label is determined algorithmically by
     the processing application.  There is no requirement to present
     the label.  For example, the label may be presented on request
     by an online system rather than put directly in the result image.
     The algorithmic rules for presenting labels is a style choice and
     and is not defined by this definition.  It is up to the processing
     application to determine how label style is specified and what
     the presentation algorithm is.
-->
<!-- %gobjref;--><!-- embed of GOBJREF declaration. -->
  ............GOBJREF DTD starts here: .......................
<!-- GOBJREF:  Uses a graphic object by reference.                    -->
<!ELEMENT   gobjref - O (label?, (%grp.obj)*) --                      -->
<!ATTLIST   gobjref id       NAME   #IMPLIED  -- ID of this reference --
                    auto     (auto) #CONREF   -- conref attribute     --
                    %link.at; -- Hyperlink attributes                 --
                    %line.1;%line.2;%line.3;%line.4; --Line attributes--
                    %box.1;%box.2;%box.3;%box.4;%box.5;
                                -- Box attributes                     --
                    %cir.1;%cir.2;%cir.3;%cir.4;  -- circle attributes--
                    %arc.at;  -- Arc attributes                       --
                    %poly.at; -- Polygon attributes                   --
                    %imag.at; -- Image attributes                     --
                    %sty.1;%sty.2;%sty.3;  -- Style attributes        --
>
<!-- The GOBJREF element enables re-use of any graphic object by
     reference.  The GOBJREF takes all relevant attributes of all
     the object types, which enables override of any attribute.
     All attributes not specified explicitly inherit the value coded
     for the source object.

     Attributes specified must be appropriate for the type of object
     refered to.  The processing application must validate attribute
     values for appropriateness and report exception conditions.
     Coding of attributes that are not relevant to the source object
     must not result in a terminal error but must be reported.

     Note that, because the GOBJREF can itself take an ID, GOBJREFs
     can be chained together.  Attributes inherit along the chain,
     with the last-specified value of any attribute taking precedence.

     When the AUTO attribute is not specified, only the object refered
     to, and not any contained objects, are used.  In other words, the
     source object's attribute values are used, but it's content is not.
     When the AUTO attribute is specified, the the object, and any
     contained objects, are used as the contents of the GOBJREFs.

     GOBJREF is especially useful in conjunction with elements contained
     in GOBJLIB.

     Support for GOBJREF is optional.  GOBJREF is required when GOBJLIB
     is supported.
-->