Movatterモバイル変換
[0]ホーム

Use of CGM as a Scalable Graphics Format
W3C NOTE18-June-1997 (Format and markup errors corrected 31 Jan 2007)
- This version:
- http://www.w3.org/pub/WWW/TR/NOTE-cgm-970618
- Editor:
- Chris Lilley,W3C
- Author:
- Roy Platon,Rutherford AppletonLaboratory
Status of this document
This document is a NOTE made available by the W3 Consortium fordiscussion only. This indicates no endorsement of its content, northat the Consortium has, is, or will be allocating any resources tothe 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 theproblems of use raised by the general nature of the CGM format.
On 31 January 2007 this note was converted to well formed and valid XHTML (previously claimed HTML 2.0, but invalid) and to use the current CSS styling for W3C NOTEs. The technical content is unchanged.
There has been a long-term requirement in the World Wide Web foran additional type of graphics object to display scalable or vectorgraphics. These are particularly useful for showing technicaldrawings and maps, where much detail can be lost in a raster imageand it is useful to zoom in on details, but can also be useful forthe display of other schematic data (ie histograms).
A detailed comparison of CGM against the Scalable GraphicsRequirement is given in thenext section.The authors believe that CGM fulfills most of the requirements in[4], but there is a danger thatunconstrained use of CGM would cause problems with portability andinteroperability. This paper is an attempt to address some of theportability issues and to recommend how to use CGM on the WorldWide Web. This will include the use of parameters to the OBJECTtag, how add links to CGM and the possible definition of a Webprofile.
This paper does not attempt to describe CGM, which is fullydescribed in the ISO Standard[1] and its twoamendments[2] and[3]. The standard defines 3 versions of CGM whichhave different capabilities:
- Version 1 is the original 1992 standard,
- Version 2 added elements to support GKS, the most important wasSEGMENTS.
- Version 3 added many new drawing primitives, including curves,and more colour models.
- Version 4 is defined in[3] and addssupport for APPLICATION STRUCTURES.
This section compares CGM against the requirements raised in[4].
- Open Specification
- The specification is published in the ISO Standard[1].
- Ready Availability to casual implementor
- W3C is discussing with ISO the availability of a HTML versionof the standard. There is also a book on CGM written by the Authorsof the standard[7].
- Extensible to cope with changing requirements
- CGM has evolved over the last few years fairly rapidly, throughthe normal ISO procedures.
- Widely implemented
- There are many packages which support the import or export ofCGM version 1 and it has been adopted as the standard means oftransferring pictures in some industries.
- Reference code desirable
- Most viewers and interpreters are commercial products, but itis hoped to make some reference code available as part ofAmaya.
- Lack of subset problems
- There are still problems with interoperability of CGMs withdifferent vendors. This should be reduced by the acceptance of aWeb Profile(see below).
- Vector graphics elements
- CGM has a full set of Vector drawing elements, includingPOLYLINE, POLYMARKER, POLYGON SET and RECTANGLE.
- Curved elements
- CGM version 1 has CIRCULAR and ELLIPTICAL ARCS, which may befilled as either pies or sectors. CGM Version 3 adds PARABOLIC,HYPERBOLIC, POLYBEZIER, Non-Uniform B-Splines and Non-UniformRational B-Splines to give a rich set of curve drawingoptions.
- 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. CGMVersion 3 additionally supports CIELAB, CIELUV and CMYK colourdefinitions as well as COLOUR CALIBRATION.
- Transparency/Alpha
- CGM does not support Transparency, as it must always have aBACKGROUND colour associated with each picture. It is possible foran Interpreter to ignore this element in order to allowtransparency or opaqueness (via an Alpha value). It is alsopossible in CGM version 3 to specify TRANSPARENCY for individualcolours within a CELL ARRAY, TILE ARRAY or PATTERN TABLE, but notAlpha values.
- Layering, stenciling/masking
- CGM version 2 and up support FIGURES and SEGMENTS, which may beused 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 byselection within a CGM file using the APPLICATION STRUCTUREelements.
- Include Raster data
- Raster data can be included internally as CELL ARRAYS, whichuses an internal run length encoding. With CGM version 3 the TILEARRAY element supports additional compression schemes includingCCITT T4, CCITT T6 and JPEG.
- Zoom and Pan
- This possible through the Interpreter/Viewer. Each picture isdefined in its own World Coordinate system, which has an AspectRatio but not absolute dimensions.
- Pick single elements
- This is possible, either by associating a PICK IDENTIFIER withSEGMENT or by using the APPLICATION STRUCTURE elements. This doesrequire 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 addMetadata to a group of primitives.
- Active menus on Pick
- This is a function of the viewing software, but is is possibleto use the APPLICATION STRUCTURE PARAMETER in CGM version 4 to addmenu options to a group of primitives.
- Link to other views
- Seebelow for details on how both internaland external linking can be achieved.
- Link to external media
- Seebelow for details on how both internaland external linking can be achieved.
- Linkable from external media(#)
- Seebelow for details on how both internaland external linking can be achieved.
- Extractable Metadata
- There are many elements which can be used for Metadata.
CGM was registered as an Internet Media type in November 1995[5]. Only the Binary encoding is registeredand the registration includes two required parameters,version=n andProfileId=name. The addition ofthese 2 parameters may cause problems to some servers, as theproper mime type for most CGMs available today should be'image/cgm;version=1;ProfileId=None'. If theProfileId does not appear in the MFDESC element,asrequired, it is assumed to have the value ProfileId=None.
The only standard way to add in-line CGMs to a HTML documents isthrough the proposed OBJECT tag, using the DATA attribute for theCGM file and the TYPE attribute to specify the full Mime Type.[6]. So that the minimal tag for adding CGMinto a document would be:
<OBJECT DATA="xxx.cgm" TYPE="image/cgm;Version=1;ProfileId=None" WIDTH=200 HEIGHT=100>
Other attributes which may be used in the OBJECT tag are ID,DECLARE, ALIGN, BORDER, HSPACE, VSPACE, USEMAP, SHAPES. The use ofCLASSID and CODEBASE are not recommended, as these are systemdependent attributes for accessing single implementations TheOBJECT tag also has an additional PARAM element, which allows theHTML to pass additional data to the OBJECT. To use CGM the names ofthese PARAM name/value pairs need to be specified The question ofwhich PARAMs CGM should use is open for discussion. The followingare proposed:- SCALABLEYes|No
- States whether the CGM is fixed or can be looked at in detail.This is useful to divide icons, logos etc from browseablediagrams.
- TRANSPARENTOn|Off
- States whether the CGM should be drawn on the existingBackground.
- OPAQUENESSAlpha value
- Give an Alpha value for the opaqueness of the picture in therange 0.0 to 1.0.
- VIEWPORTtopx 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 thesub-picture either in the World Coordinates of the CGM or as apercentage of the picture, if the value is followed by a percentsign (%). This facility will allow for parts of a CGM Picture to bedisplayed at different scales in different places in thedocument.
- HALIGNtop|middle|bottom
- VALIGNleft|middle|right
- Each CGM picture has a fixed aspect ratio, determined by theVDCEXTENT element, which may not agree with the HEIGHT and WIDTHspecified by the OBJECT tag. These parameter can be used to specifywhere to place the CGM within the window specified by the OBJECTtag, ie. the gravity of the window This is different to the ALIGNattribute to OBJECT, which is used to specify where the OBJECT isplaced in the document. The default value should be MIDDLE &MIDDLE. This could be expressed using the PARAM tag as:
<PARAM name="halign" data value="middle"><PARAM name="valign" data value="middle">
Note: the data attribute is optional and could be omitted.
As a CGM can contain many pictures, it is desirable to be ableto refer to individual pictures within a CGM in a URLspecification. It is proposed that the same mechanism is used aswithin HTML files. thereforepicture.cgm#picture%202 orpicture.cgm#2 should both be allowed to refer to thesecond picture in filepicture.cgm. use This will thefirst in the following priority order:
- The Application Structure ID, if one exists (CGM version4).
- The BEGPIC identifier string.
- The absolute picture number, if a number is specified.
The default value shall be#1 ie. the first picture in thefile.Note that spaces in strings need to URL encoded.
One of the advantages of CGM version 4 is that it is possible toenclose a set of graphics primitives within an APPLICATIONSTRUCTURE and attach metadata to this structure. In the Web contextthis makes it easy to associate a URL with a part of a drawing,identified as a set of primitives rather than an area on thescreen. This should be done in a standard way, so that any CGMinterpreter can handle the link. It is therefore proposed to addthe following application structure attribute types:
- LinkURL
- The data is a string containing the uncanonical URL, which maybe a full URL eg."http://www.w3.org/pub/graphics/cgm/example.cgm", arelative URL eg. "test/test2.cgm", or even an applicationstructure within the current CGM eg. "#fillercap"
This would be in addition to the current client-side (using theSHAPES attribute in OBJECT) and server-side image maps (using theUSEMAP attribute in OBJECT), which should still be allowed. Thesehave the advantage that the URL is in the HTML Document, so that ifit changes it is easier to edit than editing the CGM file. Theirdisadvantage is that the shapes can only refer to areas on thescreen, not to sets of primitives. It may be difficult to describeareas using pixels so it is suggested that area are described asNDC (Normalized Device Coordinates) in the range 0.0 to 1.0 orpercentages of the visible area. The advantage of using APPLICATIONSTRUCTUREs is that a set of CGM primitives can be grouped togetherand used to define the link.
It would be preferable to use both methods by referring to thearea using the APPLICATION STRUCTURE ID in the document. This isnot possible with the existing definition of the OBJECT tag, whichonly allows SHAPES to define areas.
There is a requirement within documents to draw a picture on topof the existing background. This can be achieved with PNG byallocating a transparent colour or using the Alpha values. The CGMstandard specifies a background colour for each picture, which isinconsistent with this requirement. As specifiedabove, it is proposed that a Parameter to the OBJECTtag be used to say whether the background is taken from the CGM orthe document.
In each CGM there should be a FONTLIST element, which lists thenames of fonts used within the CGM. The CGM Interpreter has to mapthese fonts to ones used internally. It is possible as part ofdefininga Web Profile, that a set ofpermitted fonts are defined in the Profiles definition. The ModelProfile 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 thefollowing 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 alwayspossible, as they are determined by the generator. In CGM version 3an element FONTPROPERTIES was introduced to allow a CGM to providea list of properties of the Fonts used in the CGM. This elementshould be used as it gives a hint to the interpreter about therelative importance of each property.It would be preferable if the CGM Interpreter used the samemechanism 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 accessresources for downloading fonts when needed. This technique shouldalso 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 INDIVIDUALattributes the value is explicit within the CGM, but when BUNDLEDthe values depend on the media. It is proposed that BUNDLEDattributes will be determined by the current style, either set in astyle sheet or by value determined by the cascading.
Profiles were introduced in CGM version 3 to aid theinteroperability of CGM within a fixed community. It was originallyproposed that the Web used the Model Profile defined in[2], but it is intended to add APPLICATIONSTRUCTURE PARAMETERS, which are not in the model profile.
CGM version 3 introduced the POLYSYMBOL primitive and a SYMBOLLIBRARY element. These could be used to define a set of symbols forweb use. No symbols are yet proposed, but this facility could beuseful on the Web by defining a set of commonly used graphicsobjects. The registration of a SYMBOL LIBRARY would become part ofa Web Profile.
It will therefore be necessary to submit a proposal for a WebProfile. Are the any Restrictions or Additions required for Webuse?
- 1. The CGMStandard
- Metafile for the storage and transfer of picture descriptioninformation. ISO/IEC 8632-1/4:1992
- 2. Rules forProfiles
- CGM Amendment 1 Rules for Profiles. ISO Standard ISO/IEC8632-1:1992/Amd.1:1994.
- 3. ApplicationStructures
- CGM Amendment 2 Application structure extensions. ISO StandardISO/IEC 8632-1:1992/Amd.2:1995.
- 4. ScalableGraphics Requirements
- "W3C ScalableGraphics Requirements" Chris Lilley, May 1996.
- 5. CGM Mimetype
- CGM Mime type registration
- 6. Objects inHTML
- "Insertingobjects into HTML" Dave Raggett, Feb 1997.
- 7. The CGMHandbook
- "The CGM Handbook" Lofton R Henderson & Anne M Mumford,Academic Press, 1993, ISBN 0-12-510560-0.
- 8. InternationalStandardized Profiles
- "International Standardized Profile for CGM" ISO StandardISO/IEC 12071-1:1996.

Chris Lilley(editor)
Webmaster
Date: 1997/06/18 04:27:44
Revised $Date: 2018/10/09 13:31:53 $
[8]ページ先頭