W3C NOTE-PGML-19980410


Precision Graphics Markup Language (PGML)

World Wide Web Consortium Note 10-April-1998

This version:
http://www.w3.org/TR/1998/NOTE-PGML-19980410
Latest version:
http://www.w3.org/TR/1998/NOTE-PGML
Authors:
Nabeel Al-Shamma, Adobe Systems Incorporated
Robert Ayers, Adobe Systems Incorporated
Richard Cohn, Adobe Systems Incorporated
Jon Ferraiolo, Adobe Systems Incorporated
Martin Newell, Adobe Systems Incorporated
Roger K. de Bry, International Business Machines Corporation
Kevin McCluskey, Netscape Communications Corporation
Jerry Evans, Sun Microsystems, Inc.
Copyright 1998 Adobe Systems Incorporated. All rights reserved.


Status of this Document

This document is proposed to the World-Wide Web Consortium (W3C) as an initial draft. It is offered for review and comment by W3C members. This document is subject to change.

A list of current W3C Technical Reports, many of which are relevant to this proposal, can be found at: http://www.w3.org/TR/.

This NOTE is made available by the World Wide Web Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by this NOTE. A list of current NOTEs can be found at: http://www.w3.org/TR/.

This document is part of a complete submission to the W3C. The full submission has been acknowledged by W3C and is available at http://www.w3.org/Submission/1998/06


1. Abstract

This document is the specification for the Precision Graphics Markup Language (PGML). PGML is a 2D scalable graphics language designed to meet both the simple vector graphics needs of casual users and the precision needs of graphics artists. PGML uses the imaging model common to the PostScript® language and Portable Document Format (PDF); it also contains additional features to satisfy the needs of Web applications.


2. Introduction

2.1 Status

This is a working document. It is not meant to be a complete definition for PGML. Many sections have been left open or have been labeled Ideas for Consideration so that the working group can develop the strongest possible language specification and ensure that it is fully compatible with other W3C standards efforts.

2.2 Purpose

This is a specification for the Precision Graphics Markup Language (PGML). PGML is a 2D graphics language meant to satisfy both the Web's scalable lightweight vector graphics needs and the precision needs of graphic artists who want to ensure that their graphic designs appear on end user systems with precisely the correct fonts, color, layout and compositing that they desire.

PGML uses the imaging model common to the PostScript® language[1] and Portable Document Format (PDF)[2]. In this document, this common imaging model will be called the PDF/PostScript imaging model.

2.3 Design Principles

The following design principles have been used to guide the development of PGML:

  1. PGML should encompass the PDF/PostScript imaging model to guarantee a 2D scalable graphics capability that satisfies the needs of both both casual users and graphics professionals.
  2. PGML should extend the PDF/PostScript imaging model to satisfy the graphics requirements of the Web, particularly in terms of transparency, anti-aliasing, the hooks for animation and dynamic behaviors.
  3. PGML should be compatible with the needs of three types of Web page creators: those who want to hand-code their graphics using a text editor, those who want to generate graphics via client-side or server-side scripts, and those who want to create their graphics via a graphics authoring application.
  4. Both inline PGML (i.e., embedded within an HTML stream) and external (i.e., via URL specification) PGML should be supported.
  5. PGML and PGML processors should support progressive rendering.
  6. PGML should be highly compressible to reduce download time for complicated drawings.
  7. PGML should be scriptable.
  8. PGML needs to conveniently support simple animations such as moving a collection of objects along a motion path, transforming a collection of objects over time and changing color and opacity over time. More sophisticated animations should be possible using scripting.
  9. PGML should allow for the inclusion of private application data to enable PGML authoring applications to write then read PGML files without loss of high-level application data.
  10. PGML should be an XML[3] application and the imaging model is an instance of the RDF[14] data model.
  11. PGML should be compatible with and fully leverage all related W3C standards efforts.
  12. PGML should be fully international.
  13. Text in PGML graphics should be easily extractable by search engines and tools that aid accessibility to disabled people.

2.4 A Proven Imaging Model

PGML uses the imaging model of the PostScript language and PDF as its basis in order to provide simple-to-use graphical objects and precise visual fidelity.

This imaging model is lightweight yet robust, comprising a small number of object types, attributes and operators which can be easily leveraged to satisfy the most challenging 2D graphics needs. It is suitable for all graphics applications, from business charts and diagrams to CAD and publication-quality art. It satisfies the needs of both display applications and high-end printing. The graphic artists who build many of the most popular commercial Web sites are experienced users of PostScript-based drawing/illustration products (e.g., Adobe Illustrator, Corel Draw and Macromedia Freehand) and of PostScript-based page layout tools (e.g., Adobe PageMaker and Quark Xpress) and make considerable use of PDF in their workflow.

The PDF/PostScript imaging model has been the basis and model for many graphics systems, including PostScript language implementations in printers and PostScript display systems (e.g., NeWS, Display PostScript, ghostscript). The Macintosh OS (via QuickDraw GX), Windows (via GDI-32), various UNIX implementations (via DisplayPostScript), the Java™ programming language (via the Java 2D API) and PCL printers have all been moving in the direction of adding complete support for the PDF/PostScript imaging model.

2.5 Extensions to Satisfy the Needs of the Web

PGML extends the PDF/PostScript imaging model to add features needed for Web applications, such as transparency and anti-aliasing. Furthermore, PGML includes a simple animation component and an object model which provides the hooks necessary for sophisticated Web animation and other dynamic behaviors.

Not all graphics needs are sophisticated. To serve the needs of casual users and to improve the ability of PGML authoring applications to support save then read without data loss, PGML defines a set of simple graphics objects such as rectangles, circles, ovals and pie wedges.

2.6 Relationship to Other Web Standards

PGML is compatible to the fullest degree with the direction and specifics of other W3C standards efforts, such as HTML[4], XML[3], XSL[5], CSS[6], DOM[7] and RDF[14]. PGML is fully compatible with XML and is representable in RDF. This proposal calls for the PGML working group to work out the details of the PGML language definition to achieve the optimum compatibility and cross-standard leverage.

2.7 Relationship to the Java 2D API

The Java 2D API is a set of Java classes for advanced 2D graphics and imaging that is part of the Sun JDK 1.2[8].

The Java 2D API includes the complete PDF/PostScript imaging model together with additional features for Web applications (e.g., transparency and various extensibility features). While PGML certainly can be implemented separately from JDK 1.2, the Java 2D API does offers a potentially straightforward and cross-platform graphics engine on which to build an implementation of PGML.

The PGML working group needs to decide to what extent, if any, the PGML design should rely on the Java2D API's features and contraints.


3. PGML Features

3.1 Required Features to Achieve the PDF/PostScript Imaging Model

PGML is built upon the proven foundation of the PDF/PostScript imaging model. For the full definitions of the PostScript language and PDF, refer to the PostScript Language Reference Manual - Second Edition[1] and the Portable Document Format[2] Reference Manual (version 1.2). A summary of the components of this imaging model follows:

Appendix A contains a detailed chart which presents how the features described above correspond to the PostScript language, PDF and the proposed PGML syntax presented in this document.

3.2 Features Beyond the PDF/PostScript Imaging Model

PGML requires the following additional features to satisfy the needs of the Web:

The following features would greatly benefit end users and thus should be considered for inclusion in PGML:

PGML has a small but powerful set of capabilities which will satisfy most graphics needs. To provide additional capabilities, PGML needs a strong extensibility mechanism which allows its capabilities to be extended in the following ways:


4. PGML Overview

A PGML drawing comprises a collection of one or more graphical objects -- path objects, shape objects, image objects and text objects. The visual appearance of an object, when it is drawn, is determined in part by a number of parameters. For example, a path object will be filled by a particular color, and a text object will be drawn using a particular font. The collection of such parameters is termed the graphics state. PGML provides the means for specifying objects, and for determining the parameters in the graphics state when objects are drawn.

This section first describes the general form of a PGML drawing, and shows how the graphics state parameters are specified. The different sorts of object -- path objects, shape objects, image objects and text objects -- are then described. Finally, general issues such as coordinate systems and transparency are addressed.

At this time, some parts of PGML have been thought through in great detail and are well-specified, whereas other parts are less concrete. Relatively minor issues that are not well-specified are identified as such in this section. More significant incompletely specified issues are dealt with in Section 5, Ideas for Consideration.

Most of the features described in this section correspond exactly to features from the PostScript language and PDF. Refer to the reference manuals for these two formats for additional details on these features[1, 2].

4.1 PGML Structure

The following shows a trivial PGML file with no content:

<?xml version="1.0"?>
<!DOCTYPE pgml SYSTEM "pgml.dtd">
<pgml>
  <!-- Insert drawing elements here -->
</pgml>

Between <pgml> and </pgml> are an optional <head> element followed by the elements that describe the drawing. The <head> element specifies shared resources such as extension definitions (see Extensibility below), gradient definitions (see "lineargradient" paint server below) and pattern definitions (see "pattern" paint server below).

The simplest drawings can be described by a sequence of drawing elements. The following example draws a rectangle:

...
<pgml>
  <rectangle x="100" y="100" width="100" height="100" />
</pgml>

4.2 Grouping and Naming Collections of Drawing Elements

If several drawing elements share similar attributes, they can be collected together using a <group> element. For example:

...
<pgml>
  <group fillcolor="red">
  	 <rectangle x="100" y="100" width="100" height="100" />
  	 <rectangle x="300" y="100" width="100" height="100" />
  </group>
  <group fillcolor="blue">
    <rectangle x="100" y="300" width="100" height="100" />
    <rectangle x="300" y="300" width="100" height="100" />
  </group>
</pgml>

A group of drawing elements, as well as individual objects, can be given a name. The following example organizes the drawing elements into two groups and assigns a name to each group:

...
<pgml>
  <group name="OBJECT1">
    <rectangle x="100" y="100" width="100" height="100" />
  </group>
  <group name="OBJECT2">
    <circle cx="150" cy="300" r="25" />
  </group>
</pgml>

Named groups are needed for several purposes such as animation and re-usable objects.

A <group> element can contain other <group> elements nested within it, to an arbitrary depth.

Any drawing element that is not contained within a <group> is treated as if it was in its own group.

4.3 Graphics State

The exact effect of drawing a graphics or text object is determined by parameters such as the current line thickness, font and fill color. These parameters are part of the graphics state. With a few exceptions, the parameters of the PGML graphics state are the same as those of the PDF graphics state as described in Section 7.2 of the PDF Reference Manual[2].

The following tables list the parameters in the graphics state. For each parameter, the tables list the attributes that specify the parameter.

 

General graphics state attributes:

Description

Attribute Default value
current transformation matrix concat See Section 4.3.1
clipping path clippath viewport bounding box
current point   none

Fill and stroke graphics state attributes:

Description

Attribute Default value
fill fill 1
fill rule fillrule nonzero
fill color fillcolor black
fill color space fillcolorspace sRGB
fill paint server fillpaintserver color
stroke stroke 0
stroke color strokecolor black
stroke color space strokecolorspace sRGB
stroke paint server strokepaintserver color
opacity opacity 1
anti-aliasing control antialias 1

Path stroking-specific graphics state attributes:

Description

Attribute Default value
line cap style linecap 0
line dash pattern dasharray, dashoffset empty(=solid), 0
line join style linejoin 0
line width linewidth 1
miter limit miterlimit 10

Text-specific graphics state attributes:

Description

Attribute Default value
text font font Unspecified
text size textsize Unspecified
character spacing charspacing 0
word spacing wordspacing 0
text rise textrise 0

 

In PGML, except for current point, all attributes in the graphics state are assigned via attributes on <pgml>, <group>, <path>, <text>, <textspan> or shape elements (e.g., <rectangle>). Alternatively, the attributes can be set using the CSS style mechanism. (At this time, however, like MathML, this specification allows conforming PGML processors to ignore attributes defined via the CSS style mechanism.)

Here is an example of how to specify that a rectangle should have its fillcolor be blue:

<rectangle fillcolor="blue"
           x="50" y="50" width="25" height="25"/>

Using a style instead of an attribute:

<rectangle style="fillcolor:blue" 
           x="50" y="50" width="25" height="25"/>

The scoping rules for the graphics state are as follows: In effect, when the PGML processor encounters any start tag (e.g., <pgml>, <group>, <path>, <text>, <textspan>), the graphics state is "saved." Any changes in the graphics state that occur as a result of processing the start of an element apply only to the graphics defined within that element. When the PGML processor encounters the end tag (e.g., </pgml>, </group>, </path>, </text>, </textspan>), the graphics state is "restored" to its prior condition.

All attributes are inherited from the parent element except for opacity. Unless specifically assigned, the opacity for all elements is 1.0 regardless of the setting on the parent element. See Opacity below.

4.3.1 General graphics state attributes

4.3.1.1 Coordinate systems and transformation matrices

The initial coordinate system is defined by attributes on the <pgml> element. These attributes provide an initial mapping of the PGML coordinate system onto the rectangular viewport into which the graphics are to be drawn (this viewport was defined within the HTML file). The following example illustrates the boundingbox attribute:

<pgml boundingbox="0 0 100 100">

The boundingbox defines the initial user coordinate system (user space) and the initial clipping path. The first two values represent the x and y user coordinates of the top/left corner of the drawing that should be displayed to the user. The last two values represent the width and height of the drawing in user coordinates. The initial user coordinate system is defined with the Y-axis pointing down. In the example above, the drawing has a top/left corner of (0,0) and a width and height of 100. (See below for how to change the coordinate system.)

(Idea for consideration) The mapping of this boundingbox onto a viewport within a browser is unspecified at this time pending decisions from the standards community on the larger issue of how to embed any XML-based specification (PGML, MathML, etc.) within HTML or XML Web pages. One approach would be that an HTML browser would recognize a <pgml> tag. If the <pgml> element specified attributes width and height, then the browser would provide a viewport of that size into which the PGML would be rendered. If the <pgml> element did not have attributes width and height, then the browser would use the width and height from the boundingbox to establish the size of the viewport. An additional option on the <pgml> tag would indicate whether to preserve aspect ratio in the event of scaling to fit.

Inside a PGML document, the coordinate system can be changed by specifying a transformation matrix. Transformation matrices in PGML work just as they do in PDF. Transformations alter coordinate systems, not objects. A transformation matrix in PGML specifies the transformation from the transformed (new) coordinate system to the untransformed (old) coordinate system. All coordinates used after the transformation are specified in the transformed coordinate system.

Transformations are specified via the concat attribute that can be used with most PGML elements. The value of the concat attribute is a sequence of 6 numbers separated by spaces which represents an arbitrary 2x3 matrix in the form of six values: a b c d e f, defined in the same way as in PDF[2]. The given matrix is concatenated with the current transformation matrix to produce a new transformation matrix. For example, the following matrix flips the coordinate system so that the origin is at the lower left and the Y-axis points up. It then draws a rectangle at the lower left of the viewport:

<pgml boundingbox="0 0 100 100">
  <group concat="1 0 0 -1 0 100">
    <rectangle x="0" y="0" width="25" height="25"/>
  </group>
</pgml>

4.3.1.2 Clipping path

The clipping path restricts the region to which paint can be applied. Any parts of the drawing that lie outside of the region bounded by the currently active clipping path are not drawn.

A new clipping path can be establish by specifying a clippath attribute on a drawing element or <group> which provides the name of a different drawing element to use as the clipping path.

Path objects, shape objects and text objects can be used as clipping paths. (Idea for consideration) Images and objects defined via extensibility cannot be used as clipping paths.

For a given drawing element, the actual clipping path used will be the intersection of its clippath with the clippaths of all ancestors of the drawing element.

Initially, the clipping path is set to the bounds of the entire viewport into which the PGML is being drawn.

4.3.1.3 Current point

The PGML processor maintains a current point within a <path> or <text> element but not as part of the general graphics state. For more about the current point, see Path Objects and Text Objects below.

4.3.2 Fill and stroke graphics state attributes

4.3.2.1 Fill and stroke

The fill and stroke attributes determine whether path objects, shape objects and text objects should be filled or stroked. The value of the fill and stroke attributes can be 0 or 1, where a value of 1 indicates a "yes" value. (Thus, fill="1" and stroke="1" indicates that a given object should be both filled and stroked.)

4.3.2.2 Fillrule

The fillrule attribute provides the method to use in the event an object consists of an overlapping compound path. The value of fillrule effects both filling operations (see fill attribute above) and clipping operations (see Clipping path below). The value of the fillrule attribute can be:

Section 7.5.2 of the PDF Reference Manual[2] describes these rules.

4.3.2.3 Colors and color spaces

If an object is to be filled with a color (i.e., fill="1" and fillpaintserver="color"), the fillcolor attribute specifies the paint color. If an object is to be stroked (i.e., stroke="1" and strokepaintserver="color"), the strokecolor attribute specifies the paint color. Colors may be specified as a string representing either a name or a hex value in the sRGB color space.

PGML supports multiple color spaces, with sRGB being the default color space. Use the fillcolorspace and strokecolorspace attributes to specify the names of the color spaces to use. See Color Spaces below for additional information.

4.3.2.4 Other paint servers

In addition to color, objects can be filled and stroked with more sophisticated painting methods (e.g., gradients and patterns). The attributes fillpaintserver and strokepaintserver indicate the "paint server" that is currently being used. (The default paint server is "color", which means the object will be filled and stroked using the current fillcolor and strokecolor, respectively.) See Extensibility and Paint Servers below for more information.

4.3.2.5 Opacity

The opacity attribute specifies the opaqueness of graphic objects. If specified on a <group> element and opacity is less than 1.0, all elements within the group will be drawn as a collection into an offscreen bitmap. Then the offscreen bitmap will be composited into the background using the opacity value.

Opacity blending is done on a channel-by-channel basis in the sRGB color space. (Other blending strategies can be achieved using a filter extension. See Extensibility below.)

In the example below, the blue circle is drawn on top of the red rectangle opaquely into an offscreen bitmap. The resulting offscreen bitmap (i.e., the red rectangle with the blue circle inside of it) will be drawn with 25% opacity on top of the green rectangle.

<pgml>
  <group fill="1">
    <rectangle fillcolor="green"
               x="100" y="100" width="500" height="500"/>
    <group opacity=".25">
      <rectangle fillcolor="red"
                 x="200" y="200" width="200" height="200"/>
      <circle fillcolor="blue"
              cx="300" cy="300" r="50"/>
    </group>
  </group>
</pgml>

Unlike all other attributes, the opacity setting is not inherited from parent elements. Thus, unless an explicit opacity attribute is provided, the opacity for all elements is 1.0 regardless of the setting on the parent element.

4.3.2.6 Anti-aliasing control

The antialiasing attribute in the graphics state indicates whether the PGML processor should perform antialiasing when rendering its elements. This attribute is a hint to the PGML processor, which means PGML processors are not required to honor this attribute. However, it is strongly recommended that PGML processors support this attribute for both line art and text because graphics quality in many situations will be unsatisfactory without it.

4.3.3 Path stroking attributes

The path attribute parameters of the graphics state determine details of the painting of stroked paths. See Section 7.2 of the PDF Reference [2] for details.

Line cap style. The line cap style specifies the shape to be used at the ends of open subpaths when they are stroked. The value of the linecap attribute can be

Line join style. The line join style specifies the shape to be used at the corners of paths that are stroked. The value of the linejoin attribute can be

Miter limit.When two line segments meet at a sharp angle and mitered joins have been specified as the line join style, it is possible for the miter to extend far beyond the thickness of the line stroking the path. The miter limit imposes a limit on the ratio of the miter length to the line width. The value of the miterlimit attribute must be a number greater or equal to 1.

Line dash pattern. The line dash pattern controls the pattern of dashes and gaps used to stroke paths. The value of the dasharray attribute is a list of comma-separated numbers that specify the lengths of alternating dashes and gaps. The value of the dashoffset attribute specifies the distance into the dash pattern to start the dash. Both the dasharray lengths and the dashoffset value are measured in user space units.

Line width.The line width specifies the thickness of the line used to stroke a path and is measured in user space units.

4.3.4 Text attributes

Fonts are specified using the font attribute on <pgml>, <group>, <text> or <textspan> elements. Fonts are specified using the same specification as CSS2[6], including the ability to point to a Web font via a URL.

In addition to font, the following are the text attributes stored in the graphics state:

Here is an example of the use of the textsize attribute:

<text x="100" y="100" textsize="12">ABC</text>

(Note: the list of attributes provided above are not consistent with CSS2. This is an area for clean-up within the working group.)

4.4 Path Objects

Path objects are used to represent an outline which can be stroked, filled or used as a clipping path, or for any combination of the three.

A path is described using the concept of a current point. In an analogy with drawing on paper, the current point can be thought of as the location of the pen. The position of the pen can be changed, and lines can be drawn from its current point to a new one.

Paths represent an outline of an object which is defined in terms of moveto (set a new current point), lineto (draw a straight line), curveto (draw a curve using a cubic bezier), arc (circular arc) and closepath (draw a line to the last moveto) elements. Compound paths (i.e., a path with subpaths, each consisting of a single moveto followed by one or more lineto or curveto operations) are possible to allow effects such as "donut holes" in objects.

4.4.1 Path data

A path is specified by including <moveto>, <lineto>, <curveto>, <arc> and <closepath> elements within a <path> element. The following example specifies a path in the shape of a triangle:

<path>
  <moveto x="100" y="100"/>
  <lineto x="200" y="200"/>
  <lineto x="300" y="100"/>
  <closepath/>
</path>

The following example specifies a compound path consisting of an outer and inner rectangle:

<path>
  <moveto x="0" y="0"/>
  <lineto x="200"/>           <!-- Y hasn't changed, isn't needed -->
  <lineto         y="200"/>   <!-- X hasn't changed, isn't needed -->
  <lineto x="0"/>             <!-- Y hasn't changed, isn't needed -->
  <closepath/>
  <moveto x="50" y="50"/>
  <lineto x="150"/>           <!-- Y hasn't changed, isn't needed -->
  <lineto         y="150"/>   <!-- X hasn't changed, isn't needed -->
  <lineto x="50"/>            <!-- Y hasn't changed, isn't needed -->
  <closepath/>
</path>

A <curveto> element appends a cubic bezier curve to the path. The curve extends from the current point to the specified (x,y) using (x1,y1) and (x2,y2) as the bezier control points. After the <curveto> element is processed, the new current point is (x,y).

An <arc> element adds a circular arc to the path. Attributes x and y indicate the center of the circle. Attribute r indicates the radius of the circle. ang1 and ang2 indicate the angle of the first and second endpoints of the arc. The arc goes from the first endpoint to the second endpoint. clockwise is set to "1" for a clockwise arc or "0" (the default) for a counterclockwise arc. If there is a current point, the <arc> element causes an initial line segment to be drawn from the current point to the first endpoint. After the <arc> element is processed, the new current point is the second endpoint.

<moveto>, <lineto>, <curveto> and <arc> accept both absolute coordinates via attributes x and y (and x1, y1, x2 and y2 for <curveto>) and relative coordinates using the attributes dx and dy (and dx1, dy1, dx2 and dy2 for <curveto>). Relative coordinates are expressed as offsets from the current point at the start of the operation. (Note: if both an absolute coordinate attribute such as x and a relative coordinate attribute such as dx are used in the same element, the resulting coordinate is the sum of the two: x+dx.)

<path> elements cannot be nested.

4.4.2 Compression on path data

PGML's syntax for path data, as described above, is quite verbose and thus does not lend itself to compact data streams. Given bandwidth constraints on the Web, some compression scheme(s) are needed. Because compression might be just as applicable to other Web standards (e.g., HTML) as it is to PGML, this version of the specification leaves compression as an open issue to be resolved in the working group. For further discussion, see Compression below.

4.4.3 Drawing paths

A path can be filled (i.e., its interior is painted), stroked (i.e., its outline is painted) or used to establish a new clipping path (see Using path objects as a clipping path below), or any combination of these three. To fill a path (or any other drawing element) using the current fill attributes from the graphics state, set the fill attribute in the graphics state to "1". To stroke a path (or any other drawing element) using the current stroke attributes from the graphics state, set the stroke attribute in the graphics state to "1". (The initial values in the graphics state are fill="1" and stroke="0".)

There are two types of fill rules, non-zero winding and even-odd, which differ in their treatment of compound paths which have intersecting elements. The PostScript and PDF reference manuals[1,2] contain descriptions of the differences.

4.4.4 Using path objects as a clipping path

The clipping path from the graphics state restricts the region to which paint can be applied. Any parts of the drawing that lie outside of the region bounded by the currently active clipping path are not painted.

Initially, the clipping path is set to the bounds of the entire viewport into which the PGML document is being drawn. A new clipping path can be establish by specifying a clippath attribute on a drawing element or <group> which provides the name of a drawing element to use as the new clipping path. For a given drawing element, the actual clipping path used will be the intersection of its clippath with the clippaths of all ancestors of the drawing element.

In the following example, a triangle named "MyTriangle" is used the clipping path for "MyRectangle":

<path name="MyTriangle">
  <moveto x="0" y="400"/>
  <lineto x="200" y="0"/>
  <lineto x="400" y="400"/>
  <closepath/>
</path>
<path name="MyRectangle" clippath="MyTriangle">
  <moveto x="0" y="100"/>
  <lineto x="400"/>
  <lineto         y="300"/>
  <lineto x="0"/>
  <closepath/>
</path>

The new clipping path will be established using either non-zero winding rule or the even-odd rule, depending on the value of fill in the graphics state. (See Drawing Paths above.)

4.5 Shape Objects

PGML contains the following set of predefined graphic objects:

These shape elements are exactly equivalent to the path object that would construct the same shape. They may be stroked, filled and used as clip paths, and all the properties described above for paths apply equally to them.

For example, the following will draw a blue circle with a red outline:

<circle fill="1" fillcolor="blue" 
        stroke="1" strokecolor="red"
        cx="200" cy="200" r="100"/>

The <rectangle> object has a rounding attribute to allow for rounded rectangles.

4.6 Image Objects

Images are specified using the <img> element, which includes all relevant attributes from the HTML <img> element and is syntactically equivalent. Additionally, the PGML <img> element has the additional attributes x and y to indicate the location of the top/left corner of the image in user space. Attributes width and height specify the dimensions of the image in user space. An example:

<img x="200" y="200" width="100" height="100" src="myimage.gif"/>

4.7 Text Objects

4.7.1 Drawing text

Text strings are specified as standard XML character data within a <text> element. For example, the following will cause the string "Precision Graphics" to be drawn:

<text x="100" y="150">Precision Graphics</text>

The <text> element requires attributes x and y to indicate the start point in user space of the base line of the text string. Within a <text> element, characters are drawn in the natural direction (e.g., left-to-right for Roman fonts) for the current font. After drawing each character, the current point is advanced along the horizontal and vertical axes as determined by the character width and height information from the font.

Note: The above behavior may be insufficient to meet the needs of internationalized text. The working group needs to address this issue.

The graphics state can be changed within a <text> element using the <textspan> element. For example:

<text 
 x="100" 
 y="150">A <textspan fillcolor="blue">blue</textspan> word.</text>

<textspan> elements can be nested. <text> elements cannot be nested.

<text> elements are filled (i.e., the characters are painted) or stroked (i.e., the outlines of the characters are painted) according to the fill and stroke attributes in the graphics state.

4.7.2 Using text objects as clipping paths

The outlines of the characters in a text object can be used as a clipping path for other drawing elements by giving the text object a name and then referring to that name as the clipping path of another object or group.

In the following example, the strings "ABC" are drawn. "DEF" is also used as the clipping path for the subsequent rectangle.

<text x="120" y="35">ABC</text>
<text x="300" y="300" name="MyClipPath">DEF</text>
<rectangle clippath="MyClipPath"
           x="0" y="0" width="700" height="700" />

See Using Path Objects As A Clipping Path and Clipping Path above for more information on clipping paths.

4.7.3 Ligatures and alternative glyphs

There are situations such as ligatures, special-purpose fonts (e.g., a font for music symbols) or alternate glyphs for Asian text strings where you want the text string as presented to search engines to be different than the characters drawn on the display. To allow for ligatures or for glyphs that do not correspond to Unicode[12] characters, the <textspan> element offers the following attributes:

4.8 Color Spaces

Color is defined via the fillcolor and strokecolor attributes that are part of the graphics state. If the current color space is sRGB or CalRGB, then fillcolor and strokecolor can be specified using the same color specification rules available for HTML and CSS.

PGML defines all colors using well-defined abstract color spaces. The two built-in color spaces are sRGB (the default color space) and ICCProfile.

If the current color space is set to "ICCProfile", then the PGML processor will use the attributes ICCProfileName for the name of the profile to use and ICCProfileSrc for the URL for the profile in the event that the profile is not available locally.

See Extensibility below for how custom color spaces can be added.

The attributes fillcolorspace and strokecolorspace indicate the name of the color space to use when interpreting fillcolor and strokecolor, respectively. In the following example, the Lab color space has been added using the Extensibility features (not shown). The example uses the Lab color space for filling the rectangle; thus, the color value of "65 25 88" indicates that the L* color component has a value of 65, the a* component has a value of 25 and the b* component has a value of 88:

<group fill="1" fillcolorspace="Lab" fillcolor="65 25 88">
  <rectangle x="100" y="100" width="100" height="100" />
</group>

4.9 Links

PGML linking elements are generic XML linking elements. Refer to the W3C Web site for the latest drafts.

A PGML element is designated as a link by the presence of the xml-link attribute. The possible values for the this attribute are "simple", "extended", "locator", "group" and "document". Although all of these values are valid, PGML renderers need only implement "simple" XML links to be PGML compliant. How links are indicated to the reader is left to the particular PGML processor.

Elements which specify the value of the xml-link attribute as "simple" must also specify a value for the HREF attribute. These two attributes fully specify a "simple" XML link. Thus, a typical PGML link might look like:

<path xml:link="simple" href="http://www.w3.org"> ... </path>

PGML designates that almost all elements can be used as an XML linking element. (The exact list is yet to be determined.)

4.10 Scripting

Note: The issue of how scripting relates to embedded XML data is an open issue with various working groups. The proposal below should be considered one approach. PGML should deal with scripting in a way that is consistent with other standards efforts.

PGML can be fully integrated with the scripting engine (e.g., ECMAScript[13]) that is built into browsers. Any scripts that are embedded within PGML will be interpreted by the browser's scripting engine just as if the script had been embedded within the HTML stream. Furthermore, while in the middle of interpreting a PGML stream, any document.write("some string") commands will insert "some string" into the PGML stream that is in the process of being interpreted.

For example:

<pgml>
  <head>
    <script>
      function drawtriangle()
      {
        document.write('<moveto x="100" y="100"/>');
        document.write('<lineto x="300" y="100"/>');
        document.write('<lineto x="200" y="200"/>');
        document.write('<closepath/>');
      }
    </script>
  </head>
  <script>
    drawtriangle();
  </script>
</pgml>

4.11 DOM

PGML elements can be accessed and manipulated using the W3C Document Object Model (DOM) Specification for XML. The DOM can be used for interactive editing, animations and to apply programmatic transformations to a PGML document. The hierarchical nature of a PGML document is represented as a tree structure in the DOM. Modifications allowed on this structure include the addition and deletion of individual PGML elements or subtrees of elements, and attribute modifications for individual elements. For example, the following script rotates the contents of a given document by 90 degrees by introducing a new element with the appropriate transformation:

<script> 
  var root = document.documentElement; // The <pgml> element
  var group = document.createElement("group", null); // The new <group> element 
  // Set the concat attribute of the new element to rotate 90 degrees 
  group.setAttribute("concat", "0 1 0 -1 0 0"); 
  // Move all children of the pgml element to the new group element 
  var children = root.childNodes; 
  for (var i in children) { 
    group.insertBefore(i, null); 
  } 
  // Insert the group element as the only child of the pgml element 
  root.insertBefore(group, null); 
</script>

4.12 Event handling

Any <pgml>, <group>, <img>, <path>, <text> or <textspan> element can be assigned any of the following standard HTML event handlers:

Mouse Events

Keyboard Events

State Change Events (only applicable to <pgml> element)

Additionally, PGML's scripting engine needs to have the altKey, ctrlKey and shiftKey properties available.

4.13 Extensibility

PGML defines an extensibility mechanism that allows for custom paint servers (i.e., fill and stroke types), custom object servers (e.g., 3D lettering), custom color space servers (e.g., to allow for a CMYK color space) and filter effects. Filter effects allow specialized compositing and raster image effects. An example of a compositing filter would be a matte effect which would allow any graphic to be used as an imagemask or a transparency blend other than the default channel-by-channel transparency blend in the sRGB color space. An example of a raster image effect would be a dropshadow filter, which might add a dropshadow to any graphic.

An extension of any type requires an <extension> element within the <head> section of the <pgml> element. The <extension> element gives an ID to the extension, indicates what type of extension it is (i.e., a scripting language function, a Java applet or an ActiveX control) and, if appropriate, the location of the extension. Note that a single <extension> can support multiple servers of multiple types.

For each particular type of extension, there is a corresponding element that must be provided to register a given extension: <paintserver>, <objectserver>, <colorspaceserver> and <filterserver>. Each of these elements provides a reference to the corresponding <extension> element and provides its own ID.

Here is an example of the definition and use of a custom "3DLetters" object type and a custom "pointillize" paint server. The example draws the string "3DLettering!" (which has a 3D look) and then fills a rectangle with a pointillize pattern:

<pgml>
  <head>
    <extension name="ThreeDLettersExtension" applet="3DLetters.jar"/>
    <extension name="PointillizeExtension" applet="pointillize.jar"/>
    <objectserver name="ThreeDLettersServer" 
                  extension="ThreeDLettersExtension"/>
    <paintserver  name="PointillizeServer" 
                  extension="PointillizeExtension"/>
  </head>
  <drawobject objectserver="ThreeDLettersServer" params="10 30 3DLettering!"/>
  <rectangle fillpaintserver="PointillizeServer" fillparams="25"/>
</pgml>

(Late-breaking news - The issuance of the namespace note http://www.w3.org/TR/1998/WD-xml-names-19980327, along with the processing instruction features in XML has opened up technical approaches that should fit in well with PGML's extensibility features and should replace the syntax shown above.)

4.14 Description Attribute

Each element in a PGML document can have an optional description attribute. The description attribute can contain any value and is ignored by the PGML processor. One of its possible uses is to describe in words the contents of the corresponding graphic elements in words to provide increased accessibility for the visually impaired.


5: PGML Reference

(Not yet written.)


6: DOM Interface to PGML

(Not yet written.)


7: PGML Dependencies on CSS

(Not yet written.)


8: PGML Dependencies on Browsers

(Not yet written. APIs for color management, getting imagedata from a URL, rasterizing fonts, DOM integration, scripting integration, printing, compression, an indication of the real physical size of the viewport, CSS integration, inherited current style information,...)


Appendix A: Mapping PostScript Language and PDF Features to PGML

 

Feature Corresponding PostScript language commands Corresponding PDF commands Proposed PGML
Specifying path data
                - newpath
              x y moveto
              x y lineto
x1 y1 x2 y2 x3 y3 curveto
                - closepath
                - n
              x y m
              x y l
x1 y1 x2 y2 x3 y3 c
                - h
<path>...</path>
<moveto x= y= />
<lineto x= y= />
<curveto x1= y1= x2= y2= x= y= />
<closepath />
Painting paths
                - fill
                - eofill
                - stroke
                - f
                - f*
                - S
fill="1" fillrule="nonzero"
fill="1" fillrule="evenodd"
stroke="1"
Path attributes
     array offset setdash

         linejoin setlinejoin
          linecap setlinecap
       miterlimit setmiterlimit
        linewidth setlinewidth
      array phase d

         linejoin j
          linecap J
       miterlimit M
        linewidth w
dasharray=
dashoffset=
linejoin=
linecap=
miterlimit=
linewidth=

(These attributes can also be set via a corresponding STYLE attribute and via CSS.)

Establishing a new clipping path
                - clip

                - eoclip
                - W

                - W*
<path name="xxx">
clippath="xxx" 
    fillrule="nonzero"
clippath="xxx" 
    fillrule="evenodd"
Drawing image data
      (manyparams)colorimage
                - BI
  <image attributes>
                - ID
        <image data>
                - EI
<img ... />

(Matches img element in HTML.)

Drawing text data
           string show
           string ashow
                - BT
           string Tj
            array TJ
                - ET
<text>string</text>
<textspan 
    charspacing= textrise=>
Text attributes
     ax ay string ashow
       font scale scalefont
             font setfont
      font matrix makefont

     ax ay string ashow
      proc string kshow

 

      charspacing Tc
    fontname size Tf
 
           matrix Tm
        textscale Tz
             rise Ts
      wordspacing Tw
charspacing=
textsize=
font=
concat=
textsize=
textrise=
wordspacing=

(These attributes can also be set via CSS.)

Using text outlines as paths
      string bool charpath
                7 Tr
<text name="xxx">string</text>
clippath="xxx"
 Embedded fonts Achieved by including entire font definition within the PostScript stream.  Achieved by including glyph definitions within Font Descriptor Use same strategy as CSS2 is proposing for embedded fonts, with includes the ability to specify a font via a URL.
Save/restore graphics state
                - save
                - restore
                - q
                - Q
Achieved implicitly. Each new begin element/end element pair does an implict save and restore operation, respectively, on the graphics state.
Transformation matrices
           matrix concat
            sx sy scale
            angle rotate
              x y translate
           matrix cm
concat=
Grayscale and RGB color
             gray setgray
 
            r g b setrgbcolor
             gray g
             gray G
            r g b rg
            r g b RG

The lowercase comands above represent fill colors; the uppercase commands represent stroke colors.


fillcolor=
strokecolor=

(All grayscale and RGB colors represent the colors in the sRGB color space. These attributes can also be set via a corresponding STYLE attribute and via CSS.)

CIE color
            array setcolorspace

The entries in the array specify the details of the device independent color space that will be used.

    <CalRGB options>
       <Lab options>
           intent ri
fillcolorspace=
strokecolorspace=
colorrenderingintent=

The default colorspace is sRGB. Other built-in colorspace options are CalRGB and Lab. All grayscale and RGB colors represent the colors in the sRGB color space. These attributes can also be set via a corresponding STYLE attribute and via CSS.


Appendix B: PGML Samples

<?XML version="1.0"?>
<!DOCTYPE PGML SYSTEM "pgml1.0.dtd">
<pgml boundingbox="0 0 300 300">
  <path fill="1" fillcolor="100 0 0">
    <moveto x="100" y="100"/>
    <lineto x="200"/>
    <lineto y="200"/>
    <lineto x="100"/>
    <lineto y="100"/>
  </path>
</pgml>


Appendix C: Ideas for Consideration

This section describes ideas on various features and/or designs which are presented for consideration and are expected to require considerable ensuing discussion and modification.

C.1 Nesting PGML files

A <pgml> stream can contain <pgml> elements anywhere within itself. This allows PGML authoring applications to "place" stand-alone PGML files as graphic objects within another drawing. The following example illustrates two embedded <pgml> elements. The first one is a URL reference to an external PGML file. The second places the embedded <pgml> inline:

...
<pgml>
  ...
  <pgml x="100" y="100" width="100" height="100"
        src="../drawings/rectangle.pgml" />
  <pgml x="300" y="100" width="100" height="100">
    <circle cx="150" cy="150" r="25" />
  </pgml>
  ...
</pgml>

The PGML graphics engine treats embedded <pgml> elements in the same manner as if the contained graphics had been specified within a <group> element. (Note that it is still an open standards issue on how XML will be embedded within either HTML or XML.)

C.2 Re-usable, Pre-defined Graphic Objects

For performance and convenience reasons, it is desirable to define a graphic object outside the actual graphic display list and then refer to that graphic object within the graphic display list. Two applications are for re-usable graphic symbols and pattern fills.

A re-usable graphic object is defined by a <graphic> element within the <head> element. The <graphic> can contain any combination of path data, image data and text data within it. Here is an example of the definition of a four star graphic object. (See the discussion of the "pattern" paint server below to see how to use this object to fill a rectangle with a pattern. The source of this example is the Portable Document Format Reference Manual Version 1.2 page 206):

<pgml>
  <head>
    <graphic name="fourstar"
             painttype="1"
             boundingbox="0 0 60 60"
             xstep="60" ystep="60"
             fill="1">
      <group fillcolor=".3 .3 .3">
        <path>
          <moveto x="15" y="27"/>
          <lineto x="7.947" y="5.292"/>
          <lineto x="26.413" y="18.708"/>
          <lineto x="3.587"/>
          <lineto x="22.053" y="5.292"/>
        </path>
        <path>
          <moveto x="45" y="57"/>
          <lineto x="37.947" y="35.292"/>
          <lineto x="56.413" y="48.708"/>
          <lineto x="33.587"/>
          <lineto x="52.053" y="35.292"/>
        </path>
      </group>
      <group fillcolor=".7 .7 .7">
        <path>
          <moveto x="15" y="57"/>
          <lineto x="7.947" y="35.292"/>
          <lineto x="26.413" y="48.708"/>
          <lineto x="3.587"/>
          <lineto x="22.053" y="35.292"/>
        </path>
        <path>
          <moveto x="45" y="27"/>
          <lineto x="37.947" y="5.292"/>
          <lineto x="56.413" y="18.708"/>
          <lineto x="33.587"/>
          <lineto x="52.053" y="5.292"/>
        </path>
      </group>
    </graphic>
  </head>
  ...
</pgml>

The <drawgraphic> element will draw the specified pre-defined graphic object. Here is an example:

<drawobject objectref="fourstar" x="100" y="100" width="50" height="50"/>

C.3 Paint Servers

The concept of a "paint server" provides a generalized, extensible way to allow for fill and stroke methods beyond color. Three standard paint servers could be built into PGML: a "color" paint server (the default paint server, it just fills or strokes with a solid color), a "lineargradient" paint server and a "pattern" paint server. The current paint servers for fill and stroke are determined by the current value of attributes fillpaintserver and strokepaintserver in the graphics state. (See Extensibility below for related information.)

C.3.1 The "color" paint server

The color paint server is used by default. It fills/strokes using the solid colors specified in the attributes fillcolor and strokecolor, respectively. To illustrate the color paint server, the following example fills a triangle with blue and outlines it in red:

<group fill="1" fillpaintserver="color" fillcolor="blue" 
       stroke="1" strokepaintserver="color" strokecolor="red">
  <path>
    <moveto x="100" y="100"/>
    <lineto x="200" y="200"/>
    <lineto x="300" y="100"/>
    <closepath/>
  </path>
</group>

C.3.2 The "lineargradient" paint server

Linear gradients consist of a smooth color transitions along a vector from one color to another, possibly followed by additional transitions along the same vector to other colors.

Linear gradients are specified within the <head> element and are then referenced using fillpaintserver or strokepaintserver attributes. A linear gradient is defined by a <lineargradient> element which contains <gradientstop> elements within itself. Here is an example of the definition of a gradient that consists of a smooth transition from white-to-red-to-black followed by a rectangle that is filled with that gradient:

<pgml>
  <head>
    <lineargradient name="white-to-red-to-black">
      <gradientstop offset="0" midoffset=".5" color="white"/>
      <gradientstop offset=".5" midoffset=".5" color="red"/>
      <gradientstop offset="1.0" color="black"/>
    </lineargradient>
  </head>
  <rectangle fill="1"
             fillpaintserver="lineargradient"
             fillname="white-to-red-to-black"
             fillparams="0. 0. 1. 1."
             x="100" y="100" width="100" height="100"/>
</pgml>

The offset attribute indicates where the gradient stop should be placed on the gradient vector (see fillparams below), where a value of 0 corresponds to the start of the gradient vector and a value of 1 corresponds to the end of the gradient vector. The midoffset indicates where the midpoint color (i.e., the color which is halfway between the color of this gradient stop and the following gradient stop) should be located on the segment between this gradient stop and the following gradient stop, where a value of 0 corresponds to this gradient stop and a value of 1 corresponds to the next gradient stop (default value is .5). The color indicates what color to use.

In the <rectangle> element shown above, the fillpaintserver attribute indicates that the "lineargradient" paint server should be used instead of the default "color" paint server. The fillname attribute gives the ID (i.e., the unique name) of the particular linear gradient which should be used. The fillparams attribute provides paint-server-specific values. In the case of linear gradients, fillparams consists of four values [x1 y1 x2 y2] which identify the start and end of the gradient vector , where a value of (0,0) corresponds to the lower left corner and (1,1) is the upper right corner of the object's bounding box. By default, the gradient vector goes from (0,0) to (1, 0).

C.3.3 The "pattern" paint server

The "pattern" paint server is used to fill or stroke an object using a pre-defined graphic object which is replicated ("tiled") at fixed intervals in x and y to cover the areas to be painted. To fill with a pattern, set fillpaintserver="pattern" and set fillname to the name of the graphic object which represents the pattern. To stroke with a pattern, set strokepaintserver="pattern" and set strokename to the name of the graphic object which represents the pattern. This example fills a rectangle with the "fourstar" pattern defined in the Re-usable, pre-defined graphic objects section above:

<pgml>

  <rectangle fill="1"
             fillpaintserver="pattern"
             fillname="fourstar" 
             x="100" y="100" width="100" height="100"/>
</pgml>

C.4 Z-depth and Object Visibility Control

The attributes depth and visibility are for use with animation applications.

C.4.1 The depth attribute

The depth attribute is a number which indicates the relative drawing order for that collection of graphics relative to other graphics with the same parent. depth is can only be set/changed via the DOM. (Any depth value within a PGML file will be ignored.) The default depth is 0.

C.4.2 The visibility attribute

The visibility attribute indicates whether a given object is visible or not. visibility can be changed via the DOM. The default value is "1", which indicates that the object is visible.

C.5 Private Data

Note: The issue of private data is currently an area of active discussion in the XML[3] working group. The proposal below should be considered one approach. PGML should deal with private data in the same way as all XML applications.

PGML allows private data to be included virtually anywhere in the PGML content stream in order to to enable PGML authoring applications to write then read PGML files without loss of high-level application data. Nearly any element in PGML can contain a <private> element and a <private> element can contain any content (utilizing XML namespaces, of course). For example, a business graphics authoring application might want to include some private data within the <head> section when it writes a PGML file so that it could properly reassemble the chart (a pie chart in this case) upon reading it back in:

<pgml>
  <head>
    <private>
      <myapp:piechart title="Sales by Region">
        <piece label="Northern Region" value="1.23"/>
        <piece label="Eastern Region" value="2.53"/>
        <piece label="Southern Region" value="3.89"/>
        <piece label="Western Region" value="2.04"/>
        <!-- Other private data goes here -->
      </myapp:piechart>
    </private>
  </head>
  <!-- In here would be the actual graphics elements which
       draw the pie chart -->
</pgml>

C.6 Compression

The specification recognizes that compact data streams are a requirement on the Web but leaves the choice of compression scheme(s) as an open issue for the working group.

Here are ideas for consideration regarding compression:

C.7 Animation

PGML needs to support dynamic graphics. Various features described above such as Grouping and Naming Collections of Drawing Elements and Scripting provide hooks that allow PGML to be driven via the DOM for dynamic effects. Additionally, it would be advantageous to many Web applications if commonly used simple animations (e.g, moving a collection of object along a motion path, transforming a collection of objects over time and changing the color and opacity over time) could be defined simply in PGML rather than forcing all animations to be done via scripting.

Here is an example that illustrates how simple animation support might be incorporated into PGML. PGML can contain any number of <animation> elements that define dynamic behaviors:

<pgml>
<!-- These two paths are the motion path and the speed curve -->
<path name="MyPath1" visibility="0"></path>
<path name="MyPath2" visibility="0"></path>
<!-- These two paths represent the change in 
     scale and opacity, respectively,
     of the rectangle over time -->
<path name="MyPath3" visibility="0"></path>
<path name="MyPath4" visibility="0"></path>
<!-- This is the object which get animated. (refx,refy) is the 
     reference point for motion path expressed in user space. -->
<rectangle name="MyRect" x="0" y="0" width="20" height="20"
           refx="10" refy="10" />
<!-- This is the element that tells PGML to animate the rectangle.
     This is a rather complicated animation for the purpose of 
     demonstrating the sorts of things you can do.
     This animation loops five times, with each loop taking 10 seconds. 
     For each loop, the rectangle's reference point initially is 
     attached to the start point of MyPath1. At the end of each loop,
     the reference point ends up at the end of MyPath1.
     MyPath2 provides the relative velocities to use along as
     the rectangle moves along the path.
     The rectangle rotates automatically so that it is oriented
     along the tangent of the MyPath1.
     The rectangle scales over time using the Y values of MyPath3.
     The rectangle's opacity over time is set to the Y values of 
     MyPath4.
     -->
<animation target="MyRect"
         starttime="0" duration="10" repetitions="5"
         motion="MyPath1"
         motionspeed="MyPath2"
         autorotate="1"
         scale="MyPath3"
         opacity="MyPath4" />
</pgml>

Note that the simple animation capability in the <animation> element described above does not allow for synchronizing an audio or video stream. Scripting will be needed to initiate other media types, enable scripts to start and stop animations and provide hooks to synchronize with other media types.


Appendix D: PGML DTD

<!-- Document Type Definition for the Precision Graphics
     Markup Language, PGML.
     version = 1.0 status = draft date = 23.March.1998
     syntax = XML author = jnava@adobe.com-->
<!-- =============================================================== -->
<!-- Begin Graphics State attributes
    The gs_ prefix is added to stand for Graphics State, whose
    scoping rules are as follows:
    When the PGML interpreter encounters a new pgml, group,
    path, text, textspan or predefined graphic element,
    the Graphics State is "saved." Any changes in the Graphics State
    that occur during processing these elements apply only to the
    graphics defined within the element. When the PGML interpreter
    encounters the end of the element the Graphics State is "restored"
    to its prior condition.
-->
<!--
    The value of the concat attribute is a sequence of 6 numbers
    separated by spaces which represents an arbitrary 2x3 matrix
    in the form of six values: a b c d e f. The given matrix is
    concatenated with the current transformation matrix to produce
    a new transformation matrix.
-->
<!ENTITY % gs_general_attributes
          'concat CDATA #IMPLIED
           clippath CDATA #IMPLIED'
>
<!ENTITY % gs_fillstroke_attributes
          'fill (0 | 1)  "1"
           fillrule (nonzero | evenodd)  "nonzero"
           fillcolor CDATA "black"
           fillcolorspace CDATA "sRGB"
           fillpaintserver CDATA "color"
           fillparams CDATA #IMPLIED
           fillname CDATA #IMPLIED
           stroke (0 | 1)  "0"
           strokecolor CDATA "black"
           strokecolorspace CDATA "sRGB"
           strokepaintserver CDATA "color"
           strokeparams CDATA #IMPLIED
           strokename CDATA #IMPLIED
           opacity CDATA "1"
           antialias (0 | 1)  "1"'
>
<!ENTITY % gs_stroking_attributes
          'linecap (0 | 1 | 2)  "0"
           linejoin (0 | 1 | 2)  "0"
           miterlimit CDATA "10"
           dasharray CDATA "solid"
           dashoffset CDATA "0"
           linewidth CDATA "1"'
>
<!ENTITY % gs_font_attribute 'font CDATA #IMPLIED' >
<!ENTITY % gs_text_attributes
          '%gs_font_attribute;
           textsize CDATA #IMPLIED
           charspacing CDATA "0"
           wordspacing CDATA "0"
           textrise CDATA "0"'
>
<!ENTITY % gs_all_attributes
          '%gs_general_attributes;
           %gs_fillstroke_attributes;
           %gs_stroking_attributes;
           %gs_text_attributes;'
>
<!--
    End of Graphics State attributes
-->
<!-- =============================================================== -->
<!ENTITY % event_handler_attributes
          'onmousedown     CDATA #IMPLIED
           onmouseup       CDATA #IMPLIED
           onclick         CDATA #IMPLIED
           ondblclick      CDATA #IMPLIED
           onmouseover     CDATA #IMPLIED
           onmousemove     CDATA #IMPLIED
           onmouseout      CDATA #IMPLIED
           onkeydown       CDATA #IMPLIED
           onkeypress      CDATA #IMPLIED
           onkeyup         CDATA #IMPLIED
           onload          CDATA #IMPLIED
           onunload        CDATA #IMPLIED'
>
<!-- =============================================================== -->
<!ENTITY % base_content_model
         '(pgml | group |  path | img | text | rectangle |
           circle | ellipse | piewedge | script | private |
          drawobject | animation)*'
>
<!ENTITY % base_content_attributes
          '%gs_all_attributes;
            name           ID    #IMPLIED
            description    CDATA    #IMPLIED
            visibility   (0 | 1)  "1"
            xml:link       CDATA #FIXED "simple"
            href       CDATA #IMPLIED
            refx       CDATA #IMPLIED
            refy       CDATA #IMPLIED'
>
<!-- =============================================================== -->
<!--
    boundingbox takes values for x, y, width and height separated
    by a space.
-->
<!ENTITY % gs_bounding_box_attribute 'boundingbox CDATA #IMPLIED' >
<!--
    The base_content_model; pgml and head elements
-->
<!ELEMENT pgml (head?, %base_content_model;) >
<!ATTLIST pgml %base_content_attributes;
               %gs_bounding_box_attribute;
               %event_handler_attributes;
               preserveaspectratio (0 | 1)  "1"
               x            CDATA #IMPLIED
               y            CDATA #IMPLIED
               width        CDATA #IMPLIED
               height       CDATA #IMPLIED
               src          CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    head element .
-->
<!ELEMENT head (extension | objectserver | paintserver | 
                 colorspaceserver | filterserver |
                 script | private |
                 graphic | lineargradient | animation)*>

<!-- =============================================================== -->
<!--
    group element
-->
<!ELEMENT group (%base_content_model;) >
<!ATTLIST group %base_content_attributes;
                %event_handler_attributes;
>
<!-- =============================================================== -->
<!--
    path element and it's sub-elements
-->
<!ELEMENT path (private?, (moveto | lineto | curveto | arc | closepath)*) >
<!ATTLIST path    %base_content_attributes;
                  %event_handler_attributes;
                  data CDATA #IMPLIED
>
<!ELEMENT moveto EMPTY >
<!ATTLIST moveto  x       CDATA #IMPLIED
                  y       CDATA #IMPLIED
                  dx      CDATA #IMPLIED
                  dy      CDATA #IMPLIED
>
<!ELEMENT lineto EMPTY >
<!ATTLIST lineto  x       CDATA #IMPLIED
                  y       CDATA #IMPLIED
                  dx      CDATA #IMPLIED
                  dy      CDATA #IMPLIED
>
<!ELEMENT curveto EMPTY >
<!ATTLIST curveto x       CDATA #IMPLIED
                  y       CDATA #IMPLIED
                  x1      CDATA #IMPLIED
                  y1      CDATA #IMPLIED
                  x2      CDATA #IMPLIED
                  y2      CDATA #IMPLIED
                  dx      CDATA #IMPLIED
                  dy      CDATA #IMPLIED
                  dx1     CDATA #IMPLIED
                  dy1     CDATA #IMPLIED
                  dx2     CDATA #IMPLIED
                  dy2     CDATA #IMPLIED
>

<!ELEMENT arc EMPTY >
<!ATTLIST arc     x       CDATA #IMPLIED
                  y       CDATA #IMPLIED
                  dx      CDATA #IMPLIED
                  dy      CDATA #IMPLIED
                  r       CDATA #IMPLIED
                  ang1    CDATA #IMPLIED
                  ang2    CDATA #IMPLIED
                  clockwise (0 | 1)  "0"
>
<!ELEMENT closepath EMPTY >
<!-- =============================================================== -->
<!--
    predefined graphic elements
-->
<!ELEMENT rectangle EMPTY >
<!ATTLIST rectangle %base_content_attributes;
                    %event_handler_attributes;
                    x            CDATA #IMPLIED
                    y            CDATA #IMPLIED
                    width        CDATA #IMPLIED
                    height       CDATA #IMPLIED
                    rounding     CDATA #IMPLIED
>
<!ELEMENT circle EMPTY >
<!ATTLIST circle    %base_content_attributes;
                    %event_handler_attributes;
                    cx           CDATA #IMPLIED
                    cy           CDATA #IMPLIED
                    r            CDATA #IMPLIED
>
<!ELEMENT ellipse EMPTY >
<!ATTLIST ellipse   %base_content_attributes;
                    %event_handler_attributes;
                    x            CDATA #IMPLIED
                    y            CDATA #IMPLIED
                    rx           CDATA #IMPLIED
                    ry           CDATA #IMPLIED
>
<!ELEMENT piewedge EMPTY >
<!ATTLIST piewedge  %base_content_attributes;
                    %event_handler_attributes;
                    x            CDATA #IMPLIED
                    y            CDATA #IMPLIED
                    r            CDATA #IMPLIED
                    ang1         CDATA #IMPLIED
                    ang2         CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    img element
    Below, the ATTLIST only shows x, y, width, height and src, 
    but the actual ATTLIST would have (nearly) everything
    that HTML's <img> element has.
-->
<!ELEMENT img EMPTY >
<!ATTLIST img       %event_handler_attributes;
                    %gs_general_attributes;
                    x            CDATA #IMPLIED
                    y            CDATA #IMPLIED
                    width        CDATA #IMPLIED
                    height       CDATA #IMPLIED
                    src          CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    text and textspan elements
-->
<!ELEMENT text      (private?,(#PCDATA | textspan )*) >
<!ATTLIST text      %base_content_attributes;
                    %event_handler_attributes;
                    x            CDATA #IMPLIED
                    y            CDATA #IMPLIED
>
<!ELEMENT textspan (private?,(#PCDATA | textspan )*) >
<!ATTLIST textspan  %base_content_attributes;
                    %event_handler_attributes;
                    altchars     CDATA #IMPLIED
                    altglyph     CDATA #IMPLIED
                    altglyphid   CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    drawobject element
-->
<!ELEMENT drawobject (private?) >
<!ATTLIST drawobject objectserver  CDATA #IMPLIED
                     params        CDATA #IMPLIED
                     objectref     IDREF #IMPLIED
                     x             CDATA #IMPLIED
                     y             CDATA #IMPLIED
                     width         CDATA #IMPLIED
                     height        CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    script element
    Below, the ATTLIST is specified as EMPTY, but the actual
    ATTLIST would match what HTML's <script> element has.
-->
<!ELEMENT script (#PCDATA) >

<!-- =============================================================== -->
<!--
    private element
    For application-specific private data.
-->
<!ELEMENT private (#PCDATA) >

<!-- =============================================================== -->
<!--
    animation element
-->
<!ELEMENT animation (private?) >
<!ATTLIST animation  target           CDATA #IMPLIED
                     starttime        CDATA #IMPLIED
                     duration         CDATA #IMPLIED
                     repetitions      CDATA #IMPLIED
                     motion           CDATA #IMPLIED
                     motionspeed      CDATA #IMPLIED
                     autorotate       CDATA #IMPLIED
                     scale            CDATA #IMPLIED
                     scalespeed       CDATA #IMPLIED
                     rotate           CDATA #IMPLIED
                     rotatespeed      CDATA #IMPLIED
                     xtranslate       CDATA #IMPLIED
                     xtranslatespeed  CDATA #IMPLIED
                     ytranslate       CDATA #IMPLIED
                     ytranslatespeed  CDATA #IMPLIED
                     xshear           CDATA #IMPLIED
                     xshearspeed      CDATA #IMPLIED
                     yshear           CDATA #IMPLIED
                     yshearspeed      CDATA #IMPLIED
                     opacity          CDATA #IMPLIED
                     opacityspeed     CDATA #IMPLIED
                     red              CDATA #IMPLIED
                     redspeed         CDATA #IMPLIED
                     green            CDATA #IMPLIED
                     greenspeed       CDATA #IMPLIED
                     blue             CDATA #IMPLIED
                     bluespeed        CDATA #IMPLIED
                     hue              CDATA #IMPLIED
                     huespeed         CDATA #IMPLIED
                     saturation       CDATA #IMPLIED
                     saturationspeed  CDATA #IMPLIED
                     brightness       CDATA #IMPLIED
                     brightnessspeed  CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    extension element
-->
<!ELEMENT extension EMPTY >
<!ATTLIST extension name       ID    #IMPLIED
                    applet     CDATA #IMPLIED
                    class      CDATA #IMPLIED
                    proc       CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    objectserver, paintserver, colorspaceserver and filterserver elements
-->
<!ELEMENT objectserver      EMPTY >
<!ATTLIST objectserver      name       ID    #IMPLIED
                            extension  IDREF #IMPLIED
>
<!ELEMENT paintserver       EMPTY >
<!ATTLIST paintserver       name       ID    #IMPLIED
                            extension  IDREF #IMPLIED
>
<!ELEMENT colorspaceserver  EMPTY >
<!ATTLIST colorspaceserver  name       ID    #IMPLIED
                            extension  IDREF #IMPLIED
>
<!ELEMENT filterserver      EMPTY >
<!ATTLIST filterserver      name       ID    #IMPLIED
                            extension  IDREF #IMPLIED
>
<!-- =============================================================== -->
<!--
    graphic element
-->
<!ELEMENT graphic (%base_content_model;) >

<!ATTLIST graphic  fill      (0 | 1)  "0">
<!ATTLIST graphic  %base_content_attributes;
                   painttype (0 | 1)  "0"
                   boundingbox       CDATA #IMPLIED
                   xstep             CDATA #IMPLIED
                   ystep             CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    lineargradient element and it's sub-elements
-->
<!ELEMENT lineargradient ((gradientstop)*) >
<!ATTLIST lineargradient    name        ID    #IMPLIED>
<!ELEMENT gradientstop EMPTY >
<!ATTLIST gradientstop  offset       CDATA #IMPLIED
                        midoffset    CDATA #IMPLIED
                        color        CDATA #IMPLIED
>
<!-- =============================================================== -->
<!--
    End of DTD for PGML
-->


Appendix E: References

[1] "PostScript Language Reference Manual, Second Edition", Adobe Systems Incorportated, Addison-Wesley, Reading Mass., 1990. ISBN 0-201-10174-2.

[2] "Portable Document Format Reference Manual", Adobe Systems Incorportated, Addison-Wesley, Reading Mass., 1993. ISBN 0-201-62628-4 describes PDF 1.0. See http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDF for PDF 1.2.

[3] "Extensible Markup Language (XML)", Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, W3C, November 1997. See http://www.w3.org/TR/WD-xml

[4] "HTML", W3C Recommendation for HTML 4.0, December 1997, http://www.w3.org/TR.

[5] "A Proposal for XSL", Sharon Adler et al, August 1997. See http://www.w3.org/TR/NOTE-XSL-970910

[6] "Cascading Style Sheets, level 2 (CSS)", Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, W3C, November 1997. See http://www.w3.org/TR/WD-css2

[7] "Document Object Model Specification", Lauren Wood, Jared Sorensen, Steve Byrne, Robert S. Sutor, W3C, October 1997. See http://www.w3.org/TR/WD-DOM

[9] "Java 2D API", Sun Microsystems, Inc. See http://java.sun.com/products/java-media/2D/index.html

[10] "International Color Consortium Profile Format Specification, version 3.4", International Color Consortium. See ftp://sgigate.sgi.com/pub/icc/ICC34.pdf. Also see http://www.color.org for an overview of the ICC.

[11] "A Standard Default Color Space for the Internet - sRGB", Michael Stokes, Matthew Anderson, Srinivasan Chandrasekar, Ricardo Motta, W3C, Version 1.10, November 1996. See http://www.w3.org/Graphics/Color/sRGB.html

[12] "The Unicode Standard: Version 2.0", The Unicode Consortium, Addison-Wesley Developers Press, 1996. The specification also takes into consideration the corrigenda at http://www.unicode.org/unicode/uni2errata/bidi.htm.
For more information, consult the Unicode Consortium's home page at http://www.unicode.org/

[13] "ECMA-262", ECMAScript: A general purpose cross-platform programming language, ECMA June 1997, http://www.ecma.ch/ or helpdesk@ecma.ch

[14]"Resource Description Framework (RDF) Model and Syntax", Ora Lassila, Ralph R. Swick, W3C, 16 Feb 1998. See http://www.w3.org/TR/WD-rdf-syntax/