ISO/IEC 8632-3:1999
(Main)Information technology — Computer graphics — Metafile for the storage and transfer of picture description information — Part 3: Binary encoding
Information technology — Computer graphics — Metafile for the storage and transfer of picture description information — Part 3: Binary encoding
This part of ISO/IEC 8632 specifies a binary encoding of the Computer Graphics Metafile. For each of the elements specified in ISO/IEC 8632-1, this part specifies an encoding in terms of data types. For each of these data types, an explicit representation in terms of bits, octets and words is specified. For some data types, the exact representation is a function of the precisions being used in the metafile, as recorded in the Metafile Descriptor. This encoding of the Computer Graphics Metafile will, in many circumstances, minimize the effort required to generate and interpret the metafile.
Technologies de l'information — Infographie — Métafichier de stockage et de transfert des informations de description d'images — Partie 3: Codage binaire
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 8632-3
Second edition
1999-12-15
Information technology — Computer
graphics — Metafile for the storage and
transfer of picture description
information —
Part 3:
Binary encoding
Technologies de l'information — Infographie — Métafichier de stockage
et de transfert des informations de description d'images —
Partie 3: Codage binaire
Reference number
ISO/IEC 8632-3:1999(E)
©
ISO/IEC 1999
---------------------- Page: 1 ----------------------
ISO/IEC 8632-3:1999(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 8632-3:1999(E)
Contents Page
1 Scope.1
2 Conformance .1
3 Normative references .2
4 Notational conventions .2
5 Overall structure .2
5.1 General form of metafile.2
5.2 General form of pictures .2
5.3 General structure of the binary metafile.3
5.4 Structure of the command header .4
6 Primitive data forms.6
6.1 Signed integer .6
6.1.1 Signed integer at 8-bit precision .6
6.1.2 Signed integer at 16-bit precision .6
6.1.3 Signed integer at 24-bit precision .7
6.1.4 Signed integer at 32-bit precision .7
6.2 Unsigned integer.7
6.2.1 Unsigned integers at 8-bit precision.7
6.2.2 Unsigned integers at 16-bit precision.7
6.2.3 Unsigned integers at 24-bit precision.7
6.2.4 Unsigned integers at 32-bit precision.8
6.3 Character.8
6.4 Fixed point real.8
6.4.1 Fixed point real at 32-bit precision.8
6.4.2 Fixed point real at 64-bit precision.8
6.4.3 Value of fixed point reals.8
6.5 Floating point .9
6.5.1 Floating point real at 32-bit precision.9
© ISO/IEC 1999 – All rights reserved
iii
---------------------- Page: 3 ----------------------
ISO/IEC 8632-3:1999(E)
6.5.2 Floating point real at 64-bit precision .10
7 Representation of abstract parameter types.10
8 Representation of each element.15
8.1 Method of presentation .15
8.2 Delimiter elements .16
8.3 Metafile descriptor elements.18
8.4 Picture descriptor elements.25
8.5 Control elements.30
8.6 Graphical primitive elements .33
8.7 Attribute elements.41
8.8 Escape element .50
8.9 External elements.51
8.10 Segment control and segment attribute elements .52
8.11 Application structure descriptor elements.56
9 Defaults .57
10 Profile encoding rules, proforma, and Model Profile .57
10.1 Encodings .57
10.2 Metafile defaults .57
10.3 Floating point values .57
10.4 Profile proforma tables (PPF) .57
10.5 Permissible alternative coding representation .58
Annex A (normative) Formal grammar.59
Annex B (informative) Examples.61
Annex C (informative) List of binary encoding metafile element codes.64
iv © ISO/IEC 1999 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 8632-3:1999(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 8632 may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 8632-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 24, Computer graphics and image processing.
This second edition cancels and replaces the first edition (ISO/IEC 8632-3:1992), which has been technically
revised. It also incorporates Amendment 1:1994 and Amendment 2:1995. Note that the previous edition of
ISO/IEC 8632-3, published in 1992, was a first edition but second edition was indicated by error on its cover page
and in the foreword.
ISO/IEC 8632 consists of the following parts, under the general title Information technology — Computer graphics
— Metafile for the storage and transfer of picture description information:
— Part 1: Functional specification
— Part 3: Binary encoding
— Part 4: Clear text encoding
Annex A forms a normative part of this part of ISO/IEC 8632. Annexes B and C are for information only.
NOTE In previous editions of ISO/IEC 8632, Part 2 defined a Character Encoding. Part 2 was withdrawn in 1998, due to its lack
of implementation and use.
© ISO/IEC 1999 – All rights reserved
v
---------------------- Page: 5 ----------------------
ISO/IEC 8632-3:1999(E)
Introduction
0.1 Purpose of the Binary Encoding
The Binary Encoding of the Computer Graphics Metafile (CGM) provides a representation of the Metafile syntax
that can be optimized for speed of generation and interpretation, while still providing a standard means of
interchange among computer systems. The encoding uses binary data formats that are much more similar to the
data representations used within computer systems than the data formats of the other encodings.
Some of the data formats may exactly match those of some computer systems. In such cases processing is
reduced very much relative to the other standardized encodings.
On most computer systems processing requirements for the Binary Encoding will be substantially lower than
another encoding.
In cases where a computer system’s architecture does not match the standard formats used in the Binary
Encoding, and where absolute minimization of processing requirements is critical, and where interchange among
dissimilar systems does not matter, it may be more appropriate to use a private encoding, conforming to the rules
specified in clause 7 of ISO/IEC 8632-1.
0.2 Objectives
This encoding has the following features.
a) Partitioning of parameter lists: metafile elements are coded in the Binary Encoding by one or more
partitions (see clause 5); the first (or only) partition of an element contains the opcode (Element Class plus
Element Id).
b) Alignment of elements: every element begins on a word boundary. When the data of an element (whether
partitioned or not) does not terminate on an even-octet boundary, then the following element is aligned by
padding after the data of the preceding element with zero bits to the next even-octet boundary. A no-op
element is available in this encoding. It is skipped and ignored by interpreters. It may be used to align
data on machine-dependent record boundaries for speed of processing.
c) Uniformity of format: all elements have an associated parameter length value. The length is specified as
an octet count. As a result, it is possible to scan the metafile, without interpreting it, at high speed.
d) Alignment of coordinate data: at default precisions and by virtue of alignment of elements, coordinate data
always start on word boundaries. This minimises processing by ensuring, on a wide class of computing
systems, that single coordinates do not have to be assembled from pieces of multiple computer words.
e) Efficiency of encoding integer data: other data such as indexes, colour and characters are encoded as one
or more octets. The precision of every parameter is determined by the appropriate precision as given in
the Metafile Descriptor.
f) Order of bit data: in each word, or unit within a word, the bit with the highest number is the most significant
bit. Likewise, when data words are accessed sequentially, the least significant word follows the most
significant.
g) Extensibility: the arrangement of Element Class and Element Id values has been designed to allow future
growth, such as new graphical elements.
h) Format of real data: real numbers are encoded using either IEEE floating point representation or a metafile
fixed-point representation.
i) Run length encoding: if many adjacent cells have the same colour (or colour index) efficient encoding is
possible. For each run a cell count is specified followed by the colour (or colour index).
j) Packed list encoding: if adjacent colour cells do not have the same colour (or colour index) the metafile
provides bit-stream lists in which the values are packed as closely as possible.
vi © ISO/IEC 1999 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/IEC 8632-3:1999(E)
0.3 Relationship to other International Standards
The floating point representation of real data in this part of ISO/IEC 8632 is that in ANSI/IEEE 754-1986.
The representation of character data in this part of ISO/IEC 8632 follows the rules of ISO/IEC 646 and ISO 2022.
For certain elements, the CGM defines value ranges as being reserved for registration. The values and their
meanings will be defined using the established procedures (see ISO/IEC 8632-1, 6.12.)
© ISO/IEC 1999 – All rights reserved
vii
---------------------- Page: 7 ----------------------
INTERNATIONAL STANDARD ISO/IEC 8632-3:1999(E)
Information technology — Computer graphics — Metafile for the
storage and transfer of picture description information —
Part 3:
Binary encoding
1 Scope
This part of ISO/IEC 8632 specifies a binary encoding of the Computer Graphics Metafile. For each of the
elements specified in ISO/IEC 8632-1, this part specifies an encoding in terms of data types.
For each of these data types, an explicit representation in terms of bits, octets and words is specified. For some
data types, the exact representation is a function of the precisions being used in the metafile, as recorded in the
Metafile Descriptor.
This encoding of the Computer Graphics Metafile will, in many circumstances, minimize the effort required to
generate and interpret the metafile.
2 Conformance
Conformance of metafiles to ISO/IEC 8632 is defined in terms of profiles. A metafile conforms to this encoding if it
conforms to a profile and meets the following criteria:
� Each metafile element described in this part shall be encoded in the manner described in this part of this
International Standard and a profile.
� Metafile elements which are not defined in Part 1 or in this encoding are all encoded using the GENERALIZED
DRAWING PRIMITIVE or ESCAPE metafile elements as appropriate. According to the profile rules of Part 1
(see clause 9, subclause 9.5.2.8), such elements shall either be profile defined or registered, in order that the
profile be valid. Inclusion of private elements is not permissible in a valid profile of ISO/IEC 8632 and this
encoding.
� Values of index parameters, which are used as enumeration selectors from lists of implicitly defined attribute
values, shall either be standard, registered, or profile defined. The standard and registered values are all non-
negative, and the profile-defined shall be negative. Use of private, implicitly-defined negative index values
which are not profile defined is not permissible in a valid profile of ISO/IEC 8632 and this encoding.
� Values specified as being "reserved for registered values" shall not be used unless their meaning has been
registered or standardized.
� Inclusion of non-graphical data in the metafile shall be accomplished with the APPLICATION DATA element or
with the APPLICATION STRUCTURE ATTRIBUTE element.
See clause 10 for additional conformance information about this encoding.
© ISO/IEC 1999 – All rights reserved 1
---------------------- Page: 8 ----------------------
ISO/IEC 8632-3:1999(E)
3 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 8632. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC 8632 are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC 646:1991, Information technology — ISO 7-bit coded character set for information interchange.
ISO 2022:1986, Information processing — ISO 7-bit and 8-bit coded character sets — Code extension techniques.
ANSI/IEEE 754, Standard for Binary Floating Point Arithmetic.
4 Notational conventions
“Command Header” is used throughout this part of ISO/IEC 8632 to refer to that portion of a Binary-Encoded
element that contains the opcode (element class plus element id) and parameter length information (see clause 5).
Within this part, the terms “octet” and “word” have specific meanings. These meanings may not match those of a
particular computer system on which this encoding of the metafile is used.
An octet is an 8-bit entity. All bits are significant. The bits are numbered from 7 (most significant) to 0 (least
significant).
A word is a 16-bit entity. All bits are significant. The bits are numbered from 15 (most significant) to 0 (least
significant).
5 Overall structure
5.1 General form of metafile
All elements in the metafile are encoded using a uniform scheme. The elements are represented as variable length
data structures, each consisting of opcode information (element class plus element id) designating the particular
element, the length of its parameter data and finally the parameter data (if any).
The structure of the metafile is as follows. (For the purposes of this diagram only, MF is used as an abbreviation
for METAFILE.)
BEGIN MF MD
The BEGIN METAFILE element is followed by the Metafile Descriptor (MD). After this the pictures follow, each
logically independent of each other. Finally the Metafile is ended with an END METAFILE element.
5.2 General form of pictures
Apart from the BEGIN METAFILE, END METAFILE and Metafile Descriptor elements, the metafile is partitioned
into pictures. All pictures are mutually independent. A picture consists of a BEGIN PICTURE element, a Picture
Descriptor (PD), a BEGIN PICTURE BODY element, an arbitrary number of control, graphical and attribute
elements, and finally an END PICTURE element.
(For the purpose of this diagram only, PIC is used as an abbreviation for PICTURE and BEGIN BODY for BEGIN
PICTURE BODY.)
BEGIN PIC PD BEGIN BODY . END PIC
2 © ISO/IEC 1999 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 8632-3:1999(E)
5.3 General structure of the binary metafile
The binary encoding of the metafile is a logical data structure consisting of a sequential collection of bits.
For convenience in describing the length and alignment of metafile elements, fields of two different sizes are
defined within the structure. These fields are used in the remainder of this part of ISO/IEC 8632 for illustrating the
contents and structure of elements and parameters.
For measuring the lengths of elements the metafile is partitioned into octets, which are 8-bit fields.
The structure is also partitioned into 16-bit fields called words (these are logical metafile words). To optimize
processing of the binary metafile on a wide collection of computers, metafile elements are constrained to start on
word boundaries within the binary data structure (this alignment may necessitate padding an element with bits to a
word boundary if the parameter data of the element does not fill to such a boundary).
The octet is the fundamental unit of organization of the binary metafile.
The bits of an octet are numbered 7 to 0, with 7 being the most significant bit. The bits of a word are numbered 15
to 0, with 15 being the most significant bit.
b7 b0
+-+-+-+-+-+-+-+-+
octet: | |
+-+-+-+-+-+-+-+-+
msb lsb
b15 b8.b7 b0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
word: | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msb lsb
In the preceding diagram, msb means most significant bit and lsb means least significant bit.
If the consecutive bits of the binary data structure are numbered 1.N, and the consecutive octets are numbered
1.N/8, and the consecutive words are numbered 1.N/16, then the logical correspondence of bits, octets, and
words in the binary data structure is as illustrated in the following table:
metafile octet word
bit bit bit
number number number
1 b7/octet1 b15/word1
.. .
.. .
8 b0/octet1 b8/word1
9 b7/octet2 b7/word1
.. .
.. .
16 b0/octet2 b0/word1
17 b7/octet3 b15/word2
.. .
.. .
24 b0/octet3 b8/word2
25 b7/octet4 b7/word2
.. .
.. .
© ISO/IEC 1999 – All rights reserved 3
---------------------- Page: 10 ----------------------
ISO/IEC 8632-3:1999(E)
5.4 Structure of the command header
Throughout this sub-clause, the term “command” is used to denote a binary-encoded element. Metafile elements
are represented in the Binary Encoding in one of two forms — short-form commands and long-form commands.
There are two differences between them:
— a short-form command always contains a complete element; the long-form command can accommodate
partial elements (the data lists of elements can be partitioned);
— a short-form command only accommodates parameter lists up to 30 octets in length; the long-form
command accommodates lengths up to 32767 octets per data partition.
The forms differ in the format of the Command Header that precedes the parameter list. The command form for an
element (short or long) is established by the first word of the element. For the short-form, the Command Header
consists of a single word divided into three fields: element class, element id and parameter list length.
15 14 13 12 11 1098765 43210
Word 1 element class element id parameter list length
Figure 1 — Format of a short-form Command Header
The fields in the short-form Command Header are as follows:
bits 15 to 12 element class (value range 0 to 15)
bits 11 to 5 element id (value range 0 to 127)
bits 4 to 0 parameter list length: the number of octets of parameter data that follow for this command
(value range 0 to 30)
This Command Header is then followed by the parameter list.
The first word of a long-form command is identical in structure to the first word of a short-form command. The
presence of the value 11111 binary (decimal 31) in the parameter list length field indicates that the command is a
long-form command.The Command Header for the long-form command consists of two words. The second word
contains the actual parameter list length. The two header words are then followed by the parameter list.
In addition to allowing longer parameter lists, the long-form command allows the parameter list to be partitioned.
Bit 15 of the second word indicates whether the given data complete the element or more data follow. For
subsequent data partitions of the element, the first word of the long-form Command Header (containing element
class and element id) is omitted; only the second word, containing the parameter list length, is given. The
parameter list length for each partition specifies the length of that partition, not the length of the complete element.
The final partition of an element is indicated by bit 15 of the parameter list length word being zero.
15 14 13 12 11 1098765 43210
Word1 elementclass elementid 1111 1
Word 2 P parameter list length
Figure 2 — Format of a long-form Command Header
4 © ISO/IEC 1999 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 8632-3:1999(E)
The fields in the long-form Command Header are as follows:
Word 1
bits 15 to 12 element class (value range 0 to 15)
bits 11 to 5 element id (value range 0 to 127)
bits 4 to 0 binary value 11111 (decimal 31) indicating long-form
Word 2
bit 15 partition flag
— 0 for 'last' partition
— 1 for 'not-last' partition
bits 14 to 0 parameter list length: the number of octets of parameter data that follow for this command or
partition (value range 0 to 32767).
The parameter values follow the parameter list length for either the long-form or short-form commands. The
number of values is determined from the parameter list length and the type and precision of the operands. These
parameter values have the format illustrated in clause 5 of this part of ISO/IEC 8632. The parameter type for
coordinates is indicated in the Metafile Descriptor. For non-coordinate parameters, the parameter type is as
specified in clause 5 of ISO/IEC 8632-1. If the parameter type is encoding dependent, its code is specified in the
coding tables of clause 7 of this part. Unless otherwise stated, the order of parameters is as listed in clause 5 of
ISO/IEC 8632-1.
Every command is constrained to begin on a word boundary. This necessitates padding the command with a
single null octet at the end of the command if the command contains an odd number of octets of parameter data.
In addition, in elements with parameters whose precisions are shorter than one octet (i.e., those containing a 'local
colour precision’ parameter) it is necessary to pad the last data-containing octet with null bits if the data do not fill
the octet. In all cases, the parameter list length is the count of octets actually containing parameter data — it does
not include the padding octet if one is present. It is only at the end of a command that padding is performed, with
the single exception of the CELL ARRAY element.
The purpose of this command alignment constraint is to optimize processing on a wide class of computers. At the
default metafile precisions, the parameters which are expected to occur in greatest numbers (coordinates, etc) will
align on 16-bit boundaries, and Command Headers will align on 16-bit boundaries. Thus, at the default precisions
the most frequently parsed entities will lie entirely within machine words in a large number of computer designs.
The avoidance of assembling single metafile parameters from pieces of several computer words will approximately
halve the amount of processing required to recover element parameters and command header fields from a binary
metafile data stream.
This optimization may be compromised or destroyed altogether if the metafile precisions are changed from default.
Commands are still constrained to begin on 16-bit boundaries, but the most frequently expected parameters may
no longer align on such boundaries as they do at the default precisions.
The short form command header with element class 15, element id 127, and parameter list length 0 is reserved for
extension of the number of available element classes in future revisions of th
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.