NOTE-cgm-970618

Use of CGM as a Scalable Graphics Format

W3C NOTE 18-June-1997

Status of this document

This document is a NOTE made available by the W3 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 the NOTE.

This document shows how the
Computer Graphics Metafile (CGM)
[1]
meets the requirements raised in
[4]
and proposes solutions to come of the problems of use raised
by the general nature of the CGM format.

There has been a long-term requirement in the World Wide Web for
an additional type of graphics object to display scalable or vector graphics.
These are particularly useful for showing technical drawings and maps,
where much detail can be lost in a raster image and
it is useful to zoom in on details,
but can also be useful for the display of other schematic data (ie histograms).

A detailed comparison of CGM against the Scalable Graphics Requirement
is given in the next section.
The authors believe that CGM fulfills most of the requirements in
[4],
but there is a danger that unconstrained use of CGM would cause problems
with portability and interoperability.
This paper is an attempt to address some of the portability issues and
to recommend how to use CGM on the World Wide Web.
This will include the use of parameters to the OBJECT tag,
how add links to CGM and
the possible definition of a Web profile.

This paper does not attempt to describe CGM, which is fully described in
the ISO Standard
[1]
and its two amendments
[2] and
[3].
The standard defines 3 versions of CGM which have different capabilities:

Version 1 is the original 1992 standard,

Version 2 added elements to support GKS, the most important was SEGMENTS.

Version 3 added many new drawing primitives,
including curves, and more colour models.

Version 4 is defined in [3] and
adds support for APPLICATION STRUCTURES.

W3C is discussing with ISO the availability of a HTML version of the standard.
There is also a book on CGM written by the Authors of the standard
[7].

Extensible to cope with changing requirements

CGM has evolved over the last few years fairly rapidly,
through the normal ISO procedures.

Widely implemented

There are many packages which support the import or export of CGM version 1
and it has been adopted as the standard means of transferring pictures
in some industries.

Reference code desirable

Most viewers and interpreters are commercial products,
but it is hoped to make some reference code available as part of Amaya.

Lack of subset problems

There are still problems with interoperability of CGMs
with different vendors.
This should be reduced by the acceptance of a Web Profile
(see below).

Vector graphics elements

CGM has a full set of Vector drawing elements,
including POLYLINE, POLYMARKER, POLYGON SET and RECTANGLE.

Curved elements

CGM version 1 has CIRCULAR and ELLIPTICAL ARCS,
which may be filled as either pies or sectors.
CGM Version 3 adds PARABOLIC, HYPERBOLIC, POLYBEZIER,
Non-Uniform B-Splines and Non-Uniform Rational B-Splines
to give a rich set of curve drawing options.

Text and Font selection

Text and Font selection is in accordance with ISO Standards,
including a provision for UniCode characters.

Truecolour mode

CGM version 1 supports both Indexed and RGB colours.
CGM Version 3 additionally supports CIELAB, CIELUV and CMYK colour definitions
as well as COLOUR CALIBRATION.

Transparency/Alpha

CGM does not support Transparency,
as it must always have a BACKGROUND colour associated with each picture.
It is possible for an Interpreter to ignore this element
in order to allow transparency or opaqueness (via an Alpha value).
It is also possible in CGM version 3
to specify TRANSPARENCY for individual colours
within a CELL ARRAY, TILE ARRAY or PATTERN TABLE, but not Alpha values.

Layering, stenciling/masking

CGM version 2 and up support FIGURES and SEGMENTS,
which may be used for stenciling/masking and layering.

Control of line termination and mitering

This is supported in CGM version 3.

Levels of detail

This is not directly supported,
but can be achieved by selection within a CGM file
using the APPLICATION STRUCTURE elements.

Include Raster data

Raster data can be included internally as CELL ARRAYS,
which uses an internal run length encoding.
With CGM version 3 the TILE ARRAY element supports
additional compression schemes including
CCITT T4, CCITT T6 and JPEG.

Zoom and Pan

This possible through the Interpreter/Viewer.
Each picture is defined in its own World Coordinate system,
which has an Aspect Ratio but not absolute dimensions.

Pick single elements

This is possible,
either by associating a PICK IDENTIFIER with SEGMENT
or by using the APPLICATION STRUCTURE elements.
This does require that the viewer can handle this.

Switchable layers

This is possible using SEGMENTS and/or APPLICATION STRUCTURES.
Again it needs to cooperate with the viewing software.

Element grouping into semantic structure

The APPLICATION STRUCTURE elements were designed to add Metadata
to a group of primitives.

Active menus on Pick

This is a function of the viewing software,
but is is possible to use the APPLICATION STRUCTURE PARAMETER in CGM version 4
to add menu options to a group of primitives.

Link to other views

See below for details on how both internal
and external linking can be achieved.

Link to external media

See below for details on how both internal
and external linking can be achieved.

Linkable from external media(#)

See below for details on how both internal
and external linking can be achieved.

CGM was registered as an Internet Media type in November 1995
[5].
Only the Binary encoding is registered and the registration includes two
required parameters, version=n and ProfileId=name.
The addition of these 2 parameters may cause problems to some servers,
as the proper mime type for most CGMs available today should be
'image/cgm;version=1;ProfileId=None'.
If the ProfileId does not appear in the MFDESC element,as required,
it is assumed to have the value ProfileId=None.

The only standard way to add in-line CGMs to a HTML documents is
through the proposed OBJECT tag,
using the DATA attribute for the CGM file and
the TYPE attribute to specify the full Mime Type.
[6].
So that the minimal tag for adding CGM into a document would be:

Other attributes which may be used in the OBJECT tag are
ID, DECLARE, ALIGN, BORDER, HSPACE, VSPACE, USEMAP, SHAPES.
The use of CLASSID and CODEBASE are not recommended,
as these are system dependent attributes for accessing single implementations
The OBJECT tag also has an additional PARAM element,
which allows the HTML to pass additional data to the OBJECT.
To use CGM the names of these PARAM name/value pairs need to be specified
The question of which PARAMs CGM should use is open for discussion.
The following are proposed:

SCALABLE Yes|No

States whether the CGM is fixed or can be looked at in detail.
This is useful to divide icons, logos etc from browseable diagrams.

TRANSPARENT On|Off

States whether the CGM should be drawn on the existing Background.

OPAQUENESS Alpha value

Give an Alpha value for the opaqueness of the picture
in the range 0.0 to 1.0.

VIEWPORT topx topy botx boty

Gives a viewport of the CGM (a part of the picture) to display.
The values are the top-left and bottom-right corners of the sub-picture
either in the World Coordinates of the CGM or as a percentage of the picture,
if the value is followed by a percent sign (%).
This facility will allow for parts of a CGM Picture to be displayed
at different scales in different places in the document.

HALIGN top|middle|bottom

VALIGN left|middle|right

Each CGM picture has a fixed aspect ratio,
determined by the VDCEXTENT element,
which may not agree with the HEIGHT and WIDTH specified by the OBJECT tag.
These parameter can be used to specify where to place the CGM
within the window specified by the OBJECT tag,
ie. the gravity of the window
This is different to the ALIGN attribute to OBJECT,
which is used to specify where the OBJECT is placed in the document.
The default value should be MIDDLE & MIDDLE.
This could be expressed using the PARAM tag as:

As a CGM can contain many pictures,
it is desirable to be able to refer to individual pictures
within a CGM in a URL specification.
It is proposed that the same mechanism is used as within HTML files.
therefore picture.cgm#picture%202 or picture.cgm#2
should both be allowed to refer to the second picture in file
picture.cgm.
use
This will the first in the following priority order:

The Application Structure ID, if one exists (CGM version 4).

The BEGPIC identifier string.

The absolute picture number, if a number is specified.

The default value shall be #1 ie. the first picture in the file.
Note that spaces in strings need to URL encoded.

One of the advantages of CGM version 4 is that it is possible
to enclose a set of graphics primitives within an APPLICATION STRUCTURE and
attach metadata to this structure.
In the Web context this makes it easy to associate a URL
with a part of a drawing,
identified as a set of primitives rather than an area on the screen.
This should be done in a standard way,
so that any CGM interpreter can handle the link.
It is therefore proposed to add the following
application structure attribute types:

LinkURL

The data is a string containing the uncanonical URL,
which may be a full URL
eg. "http://www.w3.org/pub/graphics/cgm/example.cgm",
a relative URL
eg. "test/test2.cgm",
or even an application structure within the current CGM
eg. "#fillercap"

This would be in addition to the current client-side
(using the SHAPES attribute in OBJECT)
and server-side image maps
(using the USEMAP attribute in OBJECT),
which should still be allowed.
These have the advantage that the URL is in the HTML Document,
so that if it changes it is easier to edit than editing the CGM file.
Their disadvantage is that the shapes can only refer to areas on the screen,
not to sets of primitives.
It may be difficult to describe areas using pixels
so it is suggested that area are described as
NDC (Normalized Device Coordinates) in the range 0.0 to 1.0
or percentages of the visible area.
The advantage of using APPLICATION STRUCTUREs is
that a set of CGM primitives can be grouped together and
used to define the link.

It would be preferable to use both methods by referring to the area using the
APPLICATION STRUCTURE ID in the document.
This is not possible with the existing definition of the OBJECT tag,
which only allows SHAPES to define areas.

There is a requirement within documents
to draw a picture on top of the existing background.
This can be achieved with PNG by allocating a transparent colour or
using the Alpha values.
The CGM standard specifies a background colour for each picture,
which is inconsistent with this requirement.
As specified above,
it is proposed that a Parameter to the OBJECT tag be used to say whether the
background is taken from the CGM or the document.

In each CGM there should be a FONTLIST element,
which lists the names of fonts used within the CGM.
The CGM Interpreter has to map these fonts to ones used internally.
It is possible as part of defining a Web Profile,
that a set of permitted fonts are defined in the Profiles definition.
The Model Profile defines the following permitted fonts
[8]:

Times-Roman

Times-Bold

Times-Italic

Times-BoldItalic

Helvetica

Helvetica-Bold

Helvetica-Oblique

Helvetica-BoldOblique

Courier

Courier-Bold

Courier-Oblique

Courier-BoldOblique

Symbol

and the Advanced Presentation and Visualization Profile allows
the following in addition:

AvantGarde-Book

AvantGarde-BookOblique

AvantGarde-Demi

AvantGarde-DemiOblique

Bookman-Demi

Bookman-DemiOblique

Bookman-Light

Bookman-LightItalic

Helvetica-Narrow

Helvetica-Narrow-Bold

Helvetica-Narrow-BoldOblique

Helvetica-Narrow-Oblique

NewCenturySchlbk-Bold

NewCenturySchlbk-BoldItalic

NewCenturySchlbk-Italic

NewCenturySchlbk-Roman

Palatino-Bold

Palatino-BoldItalic

Palatino-Italic

Palatino-Roman

ZapfChancery-MediumItalic

ZapfDingbats

It is prefered that CGMs use these fonts,
but this is not always possible,
as they are determined by the generator.
In CGM version 3 an element FONTPROPERTIES was introduced to allow a CGM to
provide a list of properties of the Fonts used in the CGM.
This element should be used as it gives a hint to the interpreter about
the relative importance of each property.

It would be preferable if the CGM Interpreter used the same mechanism for font
specification and negotiation as the Browser.
W3C is currently preparing a proposal for use of fonts on the Web,
which will include a technique for matching fonts and how
to access resources for downloading fonts when needed.
This technique should also be followed in a CGM Interpreter.

In a CGM there are about 18 attributes ie. Line type and colour,
which may be either BUNDLED or INDIVIDUAL.
For INDIVIDUAL attributes the value is explicit within the CGM,
but when BUNDLED the values depend on the media.
It is proposed that BUNDLED attributes will be determined by the current style,
either set in a style sheet or by value determined by the cascading.

Profiles were introduced in CGM version 3
to aid the interoperability of CGM within a fixed community.
It was originally proposed that the Web used the Model Profile defined in
[2],
but it is intended to add APPLICATION STRUCTURE PARAMETERS,
which are not in the model profile.

CGM version 3 introduced the POLYSYMBOL primitive
and a SYMBOL LIBRARY element.
These could be used to define a set of symbols for web use.
No symbols are yet proposed,
but this facility could be useful on the Web
by defining a set of commonly used graphics objects.
The registration of a SYMBOL LIBRARY would become part of a Web Profile.

It will therefore be necessary to submit a proposal for a Web Profile.
Are the any Restrictions or Additions required for Web use?