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
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.
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.
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.
The following design principles have been used to guide the development of PGML:
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.
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.
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.
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.
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.
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:
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].
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>
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.
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.
Description |
Attribute | Default value |
|---|---|---|
| current transformation matrix | concat | See Section 4.3.1 |
| clipping path | clippath | viewport bounding box |
| current point | none |
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 |
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 |
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.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.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.
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.
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:
- textsize (in user space units)
- charspacing (amount of additional space to add between letters in user space units)
- wordspacing (amount of additional space to add between words in user space units)
- textrise (amount to move the text baseline vertically in user space units)
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.)
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.
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.
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.
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.
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.)
PGML contains the following set of predefined graphic objects:
- <rectangle/>
- <circle/>
- <ellipse/>
- <piewedge/>
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.
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"/>
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.
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.
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:
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>
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.)
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>
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
<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>
Any <pgml>, <group>, <img>, <path>, <text> or <textspan> element can be assigned any of the following standard HTML event handlers:
Additionally, PGML's scripting engine needs to have the altKey, ctrlKey and shiftKey properties available.
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.)
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.
(Not yet written.)
(Not yet written.)
(Not yet written.)
(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,...)
| 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. |
<?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>
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.
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.)
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"/>
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.)
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>
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).
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>
The attributes depth and visibility are for use with animation applications.
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.
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.
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>
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:
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.
<!-- 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
-->
[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/