EN 28632-3:1994

SLOVENSKI STANDARD
01-december-1997
Information technology - Computer graphics - Metafile for the storage and transfer
of picture description information - Part 3: Binary encoding (ISO/IEC 8632-3:1992)
Information technology - Computer graphics - Metafile for the storage and transfer of
picture description information -
Informationstechnik - Graphische Datenverarbeitung - Datei für die Speicherung und die
Übertragung von Bildinformation
Technologies de l'information - Infographie - Métafichier de stockage et de transfert des
informations de description d'
Ta slovenski standard je istoveten z: EN 28632-3:1994
ICS:
35.140 5DþXQDOQLãNDJUDILND Computer graphics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERNATIONAL
STANDARD
8632-3
Second edition
1992-l O-01
Information technology - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 3:
Binary encoding
Teclwoloqies de I’information - Infoqraphie -- Mhtafichier de stockaqe
c
et de trarisfert des informations de d&cripfion d’images ---
Par-tie 3: Codaqe binaire
.
Reference number
ISOll EC 8632-3: 1992(E)
ISO/IEC 8632-3: 1992 (E)
CONTENTS
. . . 1
. . . . . . . . . .
. . .
1 Scope . . . . . .
. . 2
* . . . . . . .
. . . . . .
2 Normative references .
. . . . . . .
. . . . . . . . .
3 Notational conventions .
. 4
. . . . e . . . . .
. . . . .
4 Overall structure . . .
. . 4
. . . . . . . . . .
. . . .
4.1 General form of metafile
. . . 4
. . . . . . . . . . * .
.
4.2 General form of pictures
l . . . . . 4
. . . . . . . . .
.
4.3 General structure of the binary metafile
. . . . . . . . 5
. . . . . . . .
4.4 Structure of the command header . .
. . 8
. . . . . . . . . .
. . . .
5 Primitive data forms . . . . . . .
. . . . 8
. . . * . . . . . .
. .
5.1 Signed integer . . . . . . . .
. . . . . . . 8
. . . . . . . . .
5.1.1 Signed integer at &bit precision
. . . . . . . . 8
. . . . . . . .
5.1.2 Signed integer at 1 &bit precision
. . . . . . . . . . 9
. . l . . 0,
5.1.3 Signed integer at 24-bit precision
. . . . . . . . . . . 9
. . . a .
5.1.4 Signed integer at 32-bit precision
n . . . . . . . . 9
. . . . . . .
5.2 Unsigned integer . . . . . . .
. . . . . . . . 9
. . . . . . .
5.2.1 Unsigned integers at &bit precision
. . . . . . * . . 9
. . . . . .
5.2.2 Unsigned integers at 16-bit precision
. . . . . . . . . 9
. . . . . .
5.2.3 Unsigned integers at 24-bit precision
. . . . . . . . . . . . l 10
. .
5.2.4 Unsigned integers at 32-bit precision
. . . . . . . . . . . . .
. .
5.3 Character . . . . . . . . . .
. . . . . . * . . . . . 10
. . .
5.4 Fixed point real . . . . . . . .
. . . . . . . . . . . . . 10
. .
5.4.1 Fixed point real at 32-bit precision .
. . . . . . . . . . a . . . 10
. .
5.4.2 Fixed point real at 64-bit precision
. . . . . . . . . . . . . .
5.4.3 Value of fixed point reals . . . .
. . . . . . . . e . . . . . .
5.5 Floating point . . . . . . . . .
. . . . . . . . . . . . . .
5.5.1 Floating point real at 32-bit precision .
. . * . . . . . . . . . 12
. . .
5.5.2 Floating point real at 64-bit precision
. . . 13
. . . . . . . . . . l .
6 Representation of abstract parameter types . .
0 ISO/IEC 1992
All rights reserved. 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 the
publisher.
ISWIEC Copyright Office l Case postale 56 l CH-1211 Gerkve 20 l Switzerland
Printed in Switzerland
ii
ISO/IEC 8632-3: 1992 (E)
. . . . . . . . . . . . . . . 18
7 Representation of each element . . . .
. . . . . . . . . . . . * . . 18
71 . Method of presentation . . . . .
. . . . . . . . . . . . . . . . . . . 19
72 . Delimiter elements
. . 21
. . . . . . . . . . . .
73 . Metafile descriptor elements . . . .
. . 28
. . . . . . . . . . . .
74 . Picture descriptor elements . . . . .
. . 33
. . . . . * . . . . . .
75 . Control elements . . . . . . . .
. . . 36
. . . . . . . . . . . .
76 . Graphical primitive elements . . .
. . . . . . . . . . 43
. . . . .
77 . Attribute elements . . . . . .
. . . . . . . . . . . . 52
. . .
78 . Escape element . . . . . . .
. . . . . . . . . . . 53
. . . .
79 External elements . . . . . . .
. . . . . . . . . . . . 54
.
7'10 . Segment control and segment attribute elements
. . . 58
. . . . . . . . . .
8 Defaults . . . . . . . . . . . l . .
. . 59
. . . . . . . . . . .
9 Conformance . . . . . . . . . . . . .
* . . . . . . . . . . . 60
.
A Formal grammar . . . . . . . . . . . .
. . . . . . . . . . . . . 63
B Examples . . . . . . . . . . . . . .
. . . . . . . . . . . . . 63
B. 1 Example 1 : BEGIN METAFILE ‘Example 1’ .
. . . . . . . . . . . . . 63
B.2 Example 2 : BEGIN PICTURE ‘Test’ . . . .
. . . . . 64
Example 3 : POLYLINE from 0,2 to l,3 to 2,l to 0,2 . . . * . . .
B.3
. . 64
B.4 Example 4 : TEXT ‘Hydrogen’ at 0,l . . . . . . . . . . . . . . .
. . . . . 65
B.5 Example 5 : Partitioned POLYLINE with 50 points . . . . . . .
. . . . . . . 66
B.6 Example 6 : METAFILE DEFAULT REPLACEMENT linewidth 0.5
. . . . . . . . 66
B.7 Example 7 : Application Data # 655 with 1OK octets (chars) of data
. . . . . . . 67
C List of binary encoding metafile element codes . . . . . . . . .
. . .
ISO/IEC 8632-3: 1992 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Conkssion)
National bodies that are members of IS0 or IEC
form the specialized system for worldwide standardization.
participate in the development of International Standards through technical committees established by the
IS0 and IEC technical conhttees
respective organization to deal with particular fields of technical activity.
collaborate in fields of mutual interest. Other international organizations, govemnlental and non-governmental, in
liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 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.
International Standard ISOIIEC 8632-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Injhnation
technology.
which has been technically revised.
This second edition cancels and replaces the first edition (IS0 8632-3:1987),
ISOIIEC 8632 consists of the following parts, under the general title Information techology - Compzrtel
graphics - MetaJiIe for the storage and transfer of picture description information :
Part I: Functional specijkation
Part 2: Character encoding
Part 3: Binary encoding
Part 4: Clear text encoding
Annex A fomis an integral part of this part of ISO/IEC 8632. Annexes B and C are for infom~ation only.
iv
ISO/IEC 8632-3: 1992 (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 encod-
ings.
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 for the other encodings.
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, conform-
ing to the rules specified in clause 7 of ISO/IEC 8632-l.
0.2 0 bjectives
This encoding has the following features.
metafile elements are coded in the Binary Encoding by one or
Partitioning of parameter lists:
a>
more partitions (see clause 4); the first (or only) partition of an element contains the opcodc (Ele-
ment Class plus Element Id).
Alignment of elements: every element begins on a word boundary. When the data of an element
b)
(whether partitioned or not) does not terminate on an even-octet boundary, then the following ele-
ment 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.
Uniformity of format: all elements have an associated parameter length value. The length is
C>
specified as an octet count. As a result, it is possible to scan the metafile, without interpreting it,
at high speed.
ISO/IEC 8632-3: 1992 (E)
Objectives
Introduction
at default precisions and by virtue of alignment of elements, coor-
Alignment of coordinate data:
d)
dinate data always start on word boundaries. This minimizes 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.
Efficiency of encoding integer data: other data such as indexes, colour and characters are
e>
encoded as one or more octets. The precision of every parameter is determined by the appropriate
precision as given in the Metafile Descriptor.
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.
Extensibility: the arrangement of Element Class and Element Id values has been designed to
g)
allow future growth, such as new graphical elements.
Format of real data: real numbers are encoded using either IEEE floating point representation or
l-0
a metafile fixed-point representation.
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).
.
Packed list encoding: if adjacent colour cells do not have the same colour (or colour index) the
J)
metafile provides bit-stream lists in which the values are packed as close1 .y as possible.
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 IS0
2022.
For certain elements, the CGM defines value ranges as being reserved for registration. The values and their
vi
ISO/IEC 8632-3: 1992 (E)
Relationship to other International Standards Introduction
vi1
This page intentionally left blank

INTERNATIONAL STANDARD ISO/IEC 8632-3 : 1992 (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.

ISO/IEC 863293:1992 (E)
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC 8632. At the time of publication, the editions indicated were valid. All standards are
subject to revision, and parties to agreements based on this part of ISO/IEC 8632 are encouraged to investi-
gate the possibility of applying the most recent editions of the standards listed below. Members of IEC and
IS0 maintain registers of currently valid International Standards.
ISOllEC 646: 1991, Information technology - IS0 7-bit coded character set for information interchange.
IS0 7-bit and a-bit coded character sets - Code extension techniques.
IS0 2022: 1986, Information processing -
ANSI/IEEE 754, Standard for Binary Floating Point Arithmetic.

ISO/IEC 8632-3: 1992 (E)
3 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 4).
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 S-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).
ISO/IEC 8632-3: 1992 (E)
4 Overall structure
4.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 abbre-
viation for METAFILE.)
BEGIN MF MD . . . END MF
The BEGIN METAFILE element is followed by the METAFILE DESCRIPTOR (MD). After this the pic-
Finally the Metafile is ended with an END
tures follow, each logically independent of each other.
METAFILE element.
4.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) element, a BEGIN PICTURE BODY element, an arbitrary
number of control, graphical and attribute elements and finally an END PICTURE element. (For the pur-
pose of this diagram only, PIC is used as an abbreviation for PICTURE and BEGIN BODY for BEGIN
PICTURE BODY .)
1 BEGIN PIG 1 PD 1 BEGIN BODY 1 . . . I END PIG I
4.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 optim-
ize 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 ele-
ment 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 num-
bered 15 to 0, with 15 being the most significant bit.

ISO/IEC 8632-3: 1992 (E)
General structure of the binary metafile
Overall structure
b7 b0
+-+-+-+-+-+-+-+-+
octet:
I I
+-+-+-+-+-+-+-+-+
msb Isb
b15 b8.b7 b0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
word:
I I I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msb lsb
If the consecutive
bits of the binary data structure are numbered 1 .N, and the consecutive octets are num-
bered l.N/8, and the consecutive words are numbered l.N/16, then the logical correspondence of bits,
octets, and words in the binary data structure is as illustrated in the following table:
octet word
metafile
. . .
bit bit bit
number number number
1 b7/octet 1 bl5/wordl
. . .
.
8 bO/octet 1 b8/word 1
9 b7/octet2 b7/word 1
.
.
16 bO/octet2 bO/word 1
17 b7/octet3 bl5/word2
.
.
24 bO/octet3 b8/word2
b7/word2
25 b7/octet4
.
.
4.4 Structure of the command header
Throughout this sub-clause, the term “command” is used to denote a binary-encoded element. Metafile ele-
ments 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 accommo-
date 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 parame-
ter list length.
ISO/IEC 8632-3: 1992 (E)
Overall structure
Structure of the command header
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
__-----------------_----------------
-------
element id I parm list lenl
1 elem class1
Word 1
____ _-----_------------- -_________---- I
_------ I I
I
Format of a short-form Command Header
Figure l-
The fields in the short-form Command Header are as follows:
element class (value range 0 to 15)
bits 15 to 12
element id (value range 0 to 127)
bits 11 to 5
parameter list length: the number of octets of parameter data that follow for this com-
bits 4 to 0
mand (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 3 1) in parameter list length field indicates that the com-
mand 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 parti-
tioned. Bit 15 of the second word indicates whether the given data complete the element or more data fol-
low. For subsequent data partitions of the element, the first word of the long-form Command Header (con-
taining 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 10 9 8 7 6 5 4 3 2 1 0
-------------------------------___--___________
Word 1 1 elem class1 element id I1 11 111
----------- -------------------_ I -----_________
I I I
Word 2 parameter list length
I p I I
I s-s I ------------------------------------------- I
Figure 2 - Format of a long-form Command Header
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).
ISO/IEC 8632-3: 1992 (E)
Structure of the command header
Overall structure
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
For non-coordinate parameters, the
parameter type for coordinates is indicated in the Metafile Descriptor.
parameter type is as specified in clause 5 of ISO/IEC 8632-l. If the parameter type is encoding dependent,
Unless otherwise stated, the order of
its code is specified in the coding tables of clause 7 of this part.
parameters is as listed in clause 5 of ISO/IEC 8632-l.
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 parame-
ter 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 con-
taining 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 (coordi-
nates, etc) will align on 16-bit boundaries, and Command Headers will align on l6-bit boundaries. Thus, at
the default precisions the most frequently parsed entities will lie entirely within machine words in a large
The avoidance of assembling single metafile parameters from pieces of
number of computer designs.
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 this part of ISO/IEC
8632. It should be treated by interpreters as any other element, as far as parsing is concerned. The next
“normal” element encountered will have an actual class value different from that encountered in the “ele-
ment class” field of the command header - it will be adjusted by a bias as will be defined in a future revi-
sion of this part of ISO/IEC 8632.

ISO/IEC 8632-3: 1992 (E)
5 Primitive data forms
The Binary Encoding of the CGM uses five primitive data forms to represent the various abstract data types
used to describe parameters in ISO/IEC 8632-l.
The primitive data forms and the symbols used to represent them are as follows.
SI Signed Integer
UI Unsigned Integer
C Character
FX Fixed Point Real
FP Floating Point Real
Each of these primitive forms (except Character) can be used in a number of precisions. The definitions of
the primitive data forms in 5.1 to 5.5 show the allowed precisions for each primitive data form. The
definitions are in terms of ‘metafile words’ which are 16-bit units.
The following terms are used in the following diagrams when displaying the form of numeric values.
msb most significant bit
lsb least significant bit
sign bit
S
The data types in the following data diagrams are illustrated for the case that the parameter begins on a
metafile word boundary. In general, parameters may align on odd or even octet boundaries, because they
may be preceded by an odd or even number of octets of other parameter data. Elements containing the
local colour precision parameter may have parameters shorter than one octet. It is possible in such cases
that the parameters will not align on octet boundaries.
5.1 Signed integer
Four precisions may be specified for signed
Signed integers are represented in “two’s complement” format.
integers: &bit, 16-bit, 24-bit and 32-bit. (Integer coordinate data encoded with this primitive data form do
not use the 8-bit precision.) In the diagrams of the following subsections, ‘value’ indicates the value for
positive integers and the two’s complement of the value for negative integers.
5.1.1 Signed integer at S-bit precision
Each value occupies half a metafile word (one octet).
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
___-----e-s- ___--------------_________-_------
value i 1sblSlmsb value i+l IsbJ
1 S lmsb
- ___________---------- I - I -----_____---_____-- I
I I
5.1.2 Signed integer at 16,bit precision
Each value occupies one metafile word.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
_______________-------------------------------
value lsbl
ISlmsb
- ____________-------------------------------- I
I I
ISO/IEC 8632-3: 1992 (E)
Primitive data forms Signed integer
5.1.3 Signed integer at 24-bit precision
Each value straddles two successive metafile words.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
__-__--------_____----------------------------
Word 1 ISlmsb value i
I I _---_--___________-----------------------___
value i lsb(Slmsb value i+l
Word 2 -
-------___________--- ___ - -_-----------_______
I I
Word 3 value i+l lsbl
____________________---------------------------
I
5.1.4 Signed integer at 32-bit precision
Each value fills two complete metafile words.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
_______________----------------------------- --
value i
Word 1 ISlmsb
_____________----------------------------
I I
Word 2 value i lsbl
-
_________________------------------------------
I
5.2 Unsigned integer
Four precisions may be specified for unsigned integers: 8-bit, 16-bit, 24-bit and 32-bit.
5.2.1 Unsigned integers at S-bit precision
Each value occupies half a metafile word.
15 14 13 12 11 10 9 8 7 6 4 2
5 3 1 0
_________________------------------------------
value i lsblmsb value i+l lsbl
lmsb
I __________________--____ I --____---__----___---- I
5.2.2 Unsigned integers at 16-bit precision
Each value occupies one metafile word.
15 14 13 12 11 10 9 8
7 6 5 4 3 2 1 0
_-________________-_---------------------------
value lsbl
Imsb
_________________------------------------------
I I
5.2.3 Unsigned integers at 24.bit precision
Each value straddles two successive metafile words.

ISO/IEC 8632-3:1992 (E)
Primitive data forms
Unsigned integer
151413121110 9 8 7 6 5 4 3 2 10
_-__-- __-_-_________------ _______-_______-_----
Word 1 Imsb value i
________------_--__-~-~---~
_______-----__-____-
I
value i+l
value i 1 sb lmsb
Word 2
____-_------_-_____ ---
______---------_-__- I
value i+l lsbl
Word 3
_________-_--__-____------ _______-----------___ I
5.2.4 Unsigned integers at 32-bit precision
Each value fills two complete metafile words.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
_________________-------------------- --_-_-_-_-
value i
Word 1 Imsb
_________-______-_--- --------___-________------
I
value i lsbl
Word 2
-____________________
___________-_--_-__------- I
5.3 Character
Each character is stored in 1 or more consecutive octets, depending upon the coding of the partkular char-
acter set. The following illustrates characters which are coded with 1 octet each.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
____________________------------ -_-_-_-____-___
Character i+l
Character i
I I
I
-_-___-__-_-_--____---
_____________-_--------- I I
I
5.4 Fixed point real
Fixed point real values are stored as two integers; the first represents the “whole part” and has the same
form as a Signed Integer (SI; see 5.1); the second represents the “fractional part” and has the same form as
an Unsigned Integer (UI; see 5.2). Two precisions may be specified for Fixed Point Reals: 32-bit or 64-bit.
5.4-l Fixed point real at 32-bit precision
Each Fixed Point Red occupies 2 complete metafile words; the first has the form of a 16-bit Signed Integer
and the second the form of a 16-bit Unsigned Integer.
15 14 13 12 11 10 9 8 7
6 5 4 3 2 1 0
--_-_------------- _---_--__--___-__-__________c
Word 1 1 Slmsb Whole
part lsbl
I __ I ________________ ----__--~--_------_----~~-~~l
Word 2 Fraction part
Imsb lsbl
I ________________-_---------------- ---______-_-- I
5.4.2 Fixed point real at 64-bit precision
Each Fixed Point Real occupies 4 complete metafile words; the first has the form of a 32-bit Signed Integer
and the second the form of a 32-bit Unsigned Integer.
ISO/IEC 8632-3: 1992 (E)
Fixed point real
Primitive data forms
15 14 13 12 11 lo 9 8 7 6 5 4 3 2 1 0
--------______________------~------------_------
Word 1 1 SI msb whole part
I __ I __________________ ---------------------------
Word 2 whole part lsb 1
I
------_____________----------------------------
Word 3 1 msb fraction part
I ___I________________---------------------------
lsb I
Word 4 fraction part
____--____--_____-___---__---_-----------______ I
54.3 Value of fixed point reals
The values of the represented real numbers are given by:
for 32 bits:
uz
for 64 bits: real-value = SI + -
i 332 1
SI stands for the “whole part” and UI stands for the “fractional part” in these equations. SI, the whole part,
is the largest integer less than or equal to the real number being represented.
5.5 Floating point
Floating Point Real values are represented in the floating point format of ANSI/IEEE 754. This format con-
tains three parts:
- a sign bit (‘s’);
- a biased exponent part (‘e’);
- a fraction part (‘f’).
The value is a function of these three values (‘s’, ‘e’ and ‘f’). If ‘s’ is ‘0’, the value is positive; if ‘s’ is ‘ I’,
the value is negative. Two precisions may be specified for Floating Point Reals: 32-bit or 64-bit. The mag-
nitude of the value is calculated as follows for 32-bit representation.
If e = 255 and f ;f 0, then the value. is undefined.
a>
If e = 255 and f = 0, then the value is as large a positive (s=O) or negative (s=l) value as possible.
b)
If 0 < e < 255, then the magnitude of the value is (1 .f)(2e-‘27).
C>
If e = 0 and f ;f 0, then the magnitude of the value is (0.j)(2-‘26).
d)
If e = 0 and f = 0, then the value is 0.
e>
The magnitude of the value is calculated as follows for 64-bit representation.
If e = 2047 and f # 0, then the value is undefined.
a>
If e = 2047 and f = 0, then the value is as large a positive (s=O) or negative (s=l) value as possi-
b)
ble .
If 0 < e < 2047, then the magnitude of the value is ( l.j)(2e-‘023).
C>
ISO/IEC 8632-3: 1992 (E)
Primitive data forms
Floating point
If e = 0 and f of 0, then the magnitude of the value is (0.j’)(2-‘022).
d)
If e = 0 and f = 0, then the value is 0.
5.51 Floating point real at 32-bit precision
Each Floating Point Real value occupies 2 metafile words. The size of each field in the value is as follows:
sign 1 bit
exponent 8 bits
fraction 23 bits
2 1 0
15 14 13 12 11 10 9 8 7 6 5 4 3
__________________________---_--I-__-__-____-__
lsblmsb Fraction
Word 1 1 Slmsb Exponent
l__l____-------------------l--------------------
lsbl
Fraction
Word 2
--- l
_-______________-___-__-_--_--------__--_--__
55.2 Floating point real at 64-bit precision
Each Floating Point Real value occupies 4 metafile words. The size of each field in the value is as follows:
sign 1 bit
exponent 11 bits
fraction 52 bits
15 12 10 9 8 7 6 5 4 3 2 1 0
14 13 11
_________________------------------------------
Exponent lsblmsb
Word 1 1 Slmsb
I __ I ______________-___ --__---__---__- I ---- - ____-
Fraction
Word 2
_-b----------b __--___-_-_----------------------
Word 3 Fraction
__________________-----------------------------
Word 4 Fraction lsbl
--
______________------------------------------- l
ISO/IEC 8632-3: 1992 (E)
6 Representation of abstract parameter types
Table 1 shows, for each of the abstract parameter types, how it is represented in the Binary Encoding of the
CGM in terms of primitive data forms. The columns of the table are as follows:
The symbol for the abstract parameter type, as it is specified in clause 5 of ISO/IEC 8632-l.
1)
The way the parameter type is constructed in terms of the primitive data forms, at the appropriate
2)
precisions. The precisions are those defined in clause 5 of ISO/IEC 8632-l.
The symbol for the number of octets required to represent one instance (occurance) of the given
3)
parameter, at the given precision, and the formula for computing the number.
The symbol for the range of values which the parameter can assume, followed by the numerical
4)
values which the parameter can assume, followed by the numerical values which define the range.
The symbols of columns 3 and 4 are used extensively in the code tables in clause 7. Also used in the code
tables are variations on those symbols:
denote the range of positive integers, range of positive reals, . .
+IR, +RR, . .
denote the range of negative integers, range of negative reals, . .
-IR, -RR, . .
denote the range of non-negative integers, range of non-negative reals, . .
++IR, ++RR, . .
m1, mR,. denotes ‘m’ integers, reals, . .
I*, R*,. denotes an unbounded number of integers, reals, . .
Combinations are used:
2R, 21, IX*,. indicates a parameter that is represented by 2 reals, then a parameter that is
represented by 2 integers and finally a parameter that contains an unlimited number
of index values.
ISO/IEC 8632-3:1992 (E)
Representation of abstract parameter types
- Representation of abstract data types
Table 1
Parameter Octets per parameter: Parameter range:
Abstract
construction from symbol and value symbol and value
symbol
primitive forms
UI at colour index BCI CIR
CI
( o.(2c@-l))
precision (tip) (=cip/8)
~~
CCOR
cc0 UI at direct BCCO
( o.(2dcp-l))
colour precision (=dcpBl
(see note 2)
(dcp)
BCD CCOR
CD (cco,cco,cco)
=(3*BCCO) (see notes 1,16)
or
BCD
(cco,cco,cco,cco)
=(4*BCCO)
BIX IXR ( -2’xp -’
IX SI at index
(=ixp/8} to
precision (ixp)
ixp -1
2 -1)
BE (-215 to 215-1 )
E SI at fixed
-
-
precision (16-bit) (see note 18)
t 23
(see note 3)
IR [-2’P-l
BI
I SI at integer
precision (ip) to
(=ip/81
2iP-1-l >
FP or FX at real BR (=sum(rp)/8) RR (=FPR or FXR,
R
precision (rp) (see note 4) see notes S,lO>
S ,SF,D UI,nC BS SR
(see note 6) (see notes 6,121
~-~
BVDC VDCR
VDC SI at VDC integer
vip-1 to
precision (vip) (=vip/8)
t-2
fpP-1-l >
or or or
FP or FX at VDC real BVDC (=sum(vrp)/8) VDCR
precision (w-p) {see note 4) (see notes 1,5,7,8)
P (VDC,VDC) BP VDCR
(=2*BVDC) (see notes 1,5,7,8)
co CI BCO (=BCI) COR (=CIR)
(see notes 9,111
or or or
CD BCO (=BCD) COR (=CCOR)
N SI at integer BN NR (-2”p-’
precision (np) to
(=np/8)
2”p-l-1)
vc I BVC (=BI} VCR (=IR)
{see note 13)
or or or
R BVC (=BR)
VCR (=RR)
VP BVP (=2*BVC)
VCR
wcvc)
(see notes 1,13,14)
ISO/IEC 8632-3: 1992 (E)
Representation of abstract parameter types
Table 1 - Representation of abstract data types (concluded)
Octets per parameter: Parameter range:
Abstract Parameter
construction from symbol and value
symbol symbol and value
primitive forms
BS BBS BSR
nU1 at fixed
precision ( 16-bit) (=2n) (see note 15)
(see note 15)
UI8 UI at fixed BUIS (=l) UI8R
precision (8-bit) (0.255)
BU132 (=4) UI32R
U132 UI at fixed
(o.232-1)
precision (32-bit)
BSDR
SDR {see note 17) n/a
VDC BSS (=BVDC) SSR (=VDCR)
ss
[see note 191
or
or or
BSS (=BR) SSR (=RR)
R
NOTES
For parameters that are composed of multiple identical components (e.g., DIRECT COLOUR, CD, and
1)
POINT, P) the range value represents the range of a single component.
For colour models RGB and CMYK a direct colour component is abstractly a real in the range [OJ]. For
2)
colour models CIELAB, CIELUV, and RGB-related it is abstractly a real in the respective colour spaces
with possibly different ranges for the direct colour components. The COLOUR VALUE EXTENT clement
provides for the mapping between a direct colour component represented as UI and the corresponding real
value.
Abstract parameter type Enumeration, E, is encoded identically to abstract type Index, IX, at 16-bit preci-
3)
sion.
The REAL PRECISION element contains an indicator (fixed or floating point) and two precision com-
4)
ponents. The symbol t’sum(rp)” in the table indicates the sum of the number of bits specified in the two
components. The same considerations apply to the VDC REAL PRECISION element and the symbol
“sum(vrp)” in the tables. The VDC REAL PRECISION control element may cause ‘vrp’ to be updated in
the body of metafile.
FPR and VDCR (when VDC are floating point reals) are computed following the ANSI/IEEE 754 floating
point standard (see clause 5 on the Floating Point Data Form).
The range for parameter types S and SF is not applicable. The range for character data is not applicable. A
6)
string is encoded as a count (unsigned integer) followed by characters. The count is a count of octets in the
string, not whole character codes (the two are equal for single byte codes, but not for multi-byte codes).
The encoding of the count is similar to the encoding of length information for metafile commands thcm-
selves. If the first octet is in the range 0.254, then it represents the character count for the complete string.
If the first octet is 255, then the next 16 bits contain the character count and a continuation flag. The first bit
is used as a continuation flag (allowing strings longer than 32767 characters) and the next 15 bits represent
the count, 0.32767, for the partial string. If the first bit is 0, then this partial string completes the string
parameter. If 1, then this partial string will be followed by another.
If the number of whole character codes in a string is ~1, and the number of octets per character code is con-
stant within the string and equal to WZ, and if the string is not continued (as a long-form string may be), then
the number of octets in the string parameter is either ~1.m + 1 or ~1.m + 3, depending upon whether the string
is short-form or long-form, respectively. If the number of octets per character code is not constant and/or
the string is a continued long-form string, then the number of octets is the string is not so easily expressed,
but is the total of the octets used in the “data” part of the string and the number of octets used for length
information.
ISO/IEC 8632-3: 1992 (E)
Representation of abstract parameter types
The abstract parameter type VDC, a single VDC value, is either a real or an integer, depending on the
7)
declaration of the metafile descriptor function VDC TYPE. Subsequent tables use a single set of symbols,
VDC, BVDC and VDCR, recognizing that they are computed differently depending on VDC TYPE.
The abstract parameter type VDC is a single value; a point, P, is an ordered pair of VDC.
s>
The parameter type symbol CO corresponds to the data type CO of ISO/IEC 8632-l. It is either direct
colour (CD) or indexed colour (CI), depending on the value specified in the COLOUR SELECTION MODE
element. The associated octets per parameter and range symbols, BCO and COR, are thus either BCI and
CIR or BCD and CDR respectively depending upon COLOUR SELECTION MODE.
10) To eliminate the need to support IEEE floating point in applications that do not need the dynamic range for
parameters of type R and VDC, a fixed point real format is provided for scalars (such as line width, charac-
ter spacing) and VDC. Fixed point reals consist of a (SI,UI) pair.
Fixed point reals (FX) apply to VDC, and to all metafile parameters of type R except for:
the metric scale factor parameter of the SCALING MODE element;
a>
the metric scde factor parameter of the DEVICE VIEWPORT SPECIFICATION MODE ele-
b)
ment;
In this encoding, these parameters are always encoded as floating point.
11) CELL ARRAY colour can optionally specify 1,2,4,8, 16,24 or 32 bit precisions for cell colours, as well as
using the default CI or CD precision.
The way in which the colour values in CELL ARRAY is represented is an extension of the representation of
single colour values. The CELL ARRAY element has a ‘cell representation flag’ which may take one of
two values:
0 run length representation
1 packed representation
For PACKED mode, each row of the cell array is represented by an array of colour values without compres-
sion. Each row starts on a word boundary. No row length information is stored since all rows arc the same
length.
The colour data thus occupies 2n,(l + [@n,--1)/16]) octets, where n, is the number of cells per row, n, is
the number of rows, p is the number of bits per colour, and [.I denotes “the greatest integer in .‘I
For RUN LENGTH encoding, the data for each row begins on a word boundary and consists of run-length-
lists for runs of constant colour value. Each ‘run-length-list’ consists of a count of a number of consecutive
cells and the representation of that colour. In terms of the abstract terms above, the colour list is of format
* and its length is *. With the exception of the first run of a row, the integer count of each
run immediately follows the colour specifier of the preceding run with no intervening padding.
12) Abstract parameter type Data Record, D, is encoded in this part similarly to string data. However, the con-
straints on character code values and the character set switching mechanisms (both those related to CHAR-
A
...