ISO 8632-3:1987
(Main)Information processing systems — Computer graphics — Metafile for the storage and transfer of picture description information — Part 3: Binary encoding
Information processing systems — Computer graphics — Metafile for the storage and transfer of picture description information — Part 3: Binary encoding
Systèmes de traitement 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)
IS0
INTERNATIONAL STANDARD
8632-3
First edition
11 987-08-01
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE DE NORMALISATION
MEXAYHAPOAHAR OPrAHM3AuMR Ti0 CTAHAAPTM3A!&îM
Information processing systems - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 3 :
Binary encoding
Systèmes de traitement de l'information - Infographie - Métafichier de stockage et de transfert
des informations de description d'images -
Partie 3 : Codage binaire
Reference number
IS0 8632-3 : 1987 (E)
---------------------- Page: 1 ----------------------
Foreword
IS0 (the International Organization for Standardization) is a worldwide federation of
national standards bodies (IS0 member bodies). The work of preparing International
IS0 technical committees. Each member
Standards is normally carried out through
body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, govern-
mental and non-governmental, in liaison with ISO, also take part in the work.
Draft International Standards adopted by the technical committees are circulated to
the member bodies for approval before their acceptance as International Standards by
the IS0 Council. They are approved in accordance with IS0 procedures requiring at
least 75 % approval by the member bodies voting.
International Standard IS0 8632-3 was prepared by Technical Committee ISO/TC 97,
information processing systems.
Users should note that all International Standards undergo revision from time to time
and that any reference made herein to any other International Standard implies its
latest edition, unless otherwise stated.
0 International Organization for Standardization, 1987 0
Printed in Switzerland
Il
---------------------- Page: 2 ----------------------
IS0 8632-3 : 1987 (E)
CONTENTS
...... 1
.. ..
O Introduction .
..
..
0.1 Purpose of the Binary Encoding .
.. ..
0.2 Objectives .
.. ...... 2
..
0.3 Relationship to other International Standards . .
...... 2
.. ..
0.4 Status of annexes .
...... 3
.. ..
1 Scope and field of application .
.. ...... 4
2 References . .
...... 5
.. ..
3 Notational conventions .
.. .. ...... 6
4 Overall structure .
...... 6
.. ..
4.1 General form of metafile .
.. ...... 6
..
4.2 General form of pictures .
...... 6
.. ..
4.3 General structure of the binary metafile .
...... 7
.. ..
4.4 Structure of the command header .
.. ...... 10
... ..
5 Primitive data forms .
...... 10
... .. ..
5.1 Signed integer .
.. ...... 10
5.1.1 Signed integer at 8-bit precision . . . .
.. ...... 10
... ..
5.1.2 Signed integer at 16-bit precision .
...... 10
.. ..
5.1.3 Signed integer at 24-bit precision . .
.. ...... 11
5.1.4 Signed integer at 32-bit precision . . .
.. .. ...... 11
5.2 Unsigned integer . .
...... 11
... .. ..
5.2.1 Unsigned integers at 8-bit precision .
.. .. ...... 11
5.2.2 Unsigned integers at 16-bit precision .
.. ...... 11
5.2.3 Unsigned integers at 24-bit precision . .
...... 12
... .. ..
5.2.4 Unsigned integers at 32-bit precision
.. .. ...... 12
5.3 Character . .
...... 12
... .. ..
5.4 Fixed point real .
.. .. ...... 12
5.4.1 Fixed point real at 32-bit precision . .
.. ...... 12
5.4.2 Fixed point real at 64-bit precision . . .
.. .. ...... 13
5.4.3 Value of fixed point reals . .
...... 13
... .. ..
5.5 Floating point .
.. .. ...... 13
5.5.1 Floating point real at 32-bit precision .
.. ...... 14
5.5.2 Floating point real at 64-bit precision . .
...... 15
.. ..
6 Representation of abstract parameter types .
.. .. ...... 19
7 Representation of each element . .
.. ...... 19
7.1 Method of presentation . . . .
...... 20
7.2 Delimiter elements . . . .
........ .. .. ...... 21
7.3 Metafile descriptor elements
.. .. ...... 24
7.4 Picture descriptor elements .
...... 26
7.5 Control elements . . . .
...... 28
........ .. ..
7.6 Graphical primitive elements
.. ...... 32
7.7 Attribute elements . . .
...... 38
7.8 Escape element . . . .
.. .. ...... 39
7.9 External elements . .
8 Defaults . . . . 40
.. .. ...... 41
9 Conformance .
---------------------- Page: 3 ----------------------
IS0 8632-3 : 1987 (E)
A Formal grammar . . 42
...... 44
B Examples .
B.l Example 1 : BEGIN METAFILE ‘Example 1’ . . 44
.......... ...... 44
B.2 Example 2 : BEGIN PICTURE ‘Test’
45
B.3 Example 3 : POLYLINE from O. 2 to 1. 3 to 2. 1 to O. 2 . .
.......... ...... 45
B.4 Example 4 : TEXT ‘Hydrogen’ at O. 1
B.5 Example 5 : Partitioned POLYLINE with 50 points . . 46
B.6 Example 6 : METAFILE DEFAULT REPLACEMENT linewidth 0.5 . 47
.....
B.7 Example 7 : Application Data # 655 with 10K octets (chars) of data 47
........ ...... 48
C List of binary encoding metafile element codes
---------------------- Page: 4 ----------------------
INTERNATIONAL STANDARD IS0 8632-3 : 1987 (E)
Information processing systems - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 3 :
Binary encoding
O 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 process-
ing 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, conforming to the rules specified in clause 7 of IS0 8632/1.
0.2 Objectives
This encoding has the following features.
Partitioning of parameter lists: metafile elements are coded in the Binary Encoding by one or
more partitions (see clause 4); the first (or only) partition of an element contains the opcode
(Element Class plus Element Id).
Alignment of elements: every element begins on a word boundary. Alignment of partitions that
require an odd number of octets is effected by padding with an octet with all bits zero. A no-op
element is available in this encoding; it is ignored. 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
specified as an octet count. As a result, it is possible to scan the metafile, without interpreting
it, at high speed.
Alignment of coordinate data: at default precisions and by virtue of alignment of elements,
coordinate 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
encoded as one or more octets. The precision of every parameter is determined by the appropri-
ate precision as given in the METAFILE DESCRPTOR.
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 word are accessed sequentially, the least significant
word follows the most significant.
1
---------------------- Page: 5 ----------------------
IS0 8632-3 : 1987 (E)
Objectives Introduction
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
h)
or a metafile fixed-point representation.
Run length encoding: if many adjacent cells have the same colour (or colour index) efficient
i)
encoding is possible. For each run, the colour (or colour index) is specified, followed by a cell
count.
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 closely as possible.
0.3 Relationship to other International Standards
The floating point representation of real data in this part of IS0 8632 is that in ANSI/IEEE 754-1986.
The representation of character data in this part of IS0 8632 follows the rules of IS0 646 and IS0 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 IS0 8632/1, 4.11.)
0.4 Status of annexes
The annexes do not form an integral part of this part of IS0 8632 but are included for information only.
---------------------- Page: 6 ----------------------
IS0 8632-3 : 1987 (E)
1 Scope and field of application
This part of IS0 8632 specifies a binary encoding of the Computer Graphics Metafile. For each of the
elements specified in IS0 8632/1, an encoding is specified in terms of a data type. 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.
3
---------------------- Page: 7 ----------------------
IS0 8632-3 : 1987 (E)
2 References
IS0 646, Information Processing-IS0 7-bit coded character set for information interchange.
IS0 2022, Information Processing-IS0 7-bit and 8-bit coded character sets-Code extension tech-
niques.
ANSI/IEEE 754, Standard for Binary Floating Point Arithmetic.
4
---------------------- Page: 8 ----------------------
IS0 8632-3 : 1987(E)
3 Not at ional convent ions
/
"Command Header" is used throughout this part to refer to that portion of a Binary-Encoded elemen4
that contains the opcode (element class plus element id) and parameter length information (see clayhe
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 8-bit entity. All bits are significant. The bits are numbered from 7 (most significant) to
û (least Significant).
A word is a 16-bit entity. All bits are significant. The bits are numbered from 15 (most significant) to O
(least significant).
5
---------------------- Page: 9 ----------------------
IS0 8632-3 : 1987 (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 vari-
able length data structures, each consisting of opcode information (element class plus element id) desig-
nating 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.)
I BEGINMF I MD I
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.
a
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 PIC-
TURE element, a PICTURE DESCRIPTOR (PD) element, a BEGIN PICTURE BODY element, an arbi-
trary 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.)
I BEGINPIC I PD I BEGIN BODY I . I END PIC 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 IS0 8632/3 for illustrat-
0
ing 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 con-
strained 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.
a word are
The bits of an octet are numbered 7 to O, with 7 being the most significant bit. The bits of
numbered 15 to O, with 15 being the most significant bit.
6
---------------------- Page: 10 ----------------------
IS0 8632-3 : 1987 (E)
General structure of the binary metafile
Overall structure
b7 bo
+- +- +-+-+-+-+-+-+
I I
octet: I I
+-+-+-+-+-+-+-+-+
msb 1 sb
b15 b8. b7 bO
+- +-+-+-+-+-+-+-+-+-+- +-+-+- +-+-+
l I I
word : I I I
+-+-+-+-+- +- +-+-+-+-+-+- +-+-+-+-+
msb 1 sb
If the consecutive bits of the binary data structure are numbered 1.N, and the consecutive octets are
numbered l.N/8, and the consecutive words are numbered l.N/l6, 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/octetl bl5/wordl
8 bO/octetl b8/wordl
9 b7/octet2 b7/wordl
bO/octet2 bO/wordl
16
17 b7/octet3 b15/word2
24 bO/octet3
b7/oc tet4
25
4.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 accom-
modate 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.
151413121110 9 8 7 6 5 4 3 2 1 O
...............................................
Word 1 I elem class! element id I parm list lenl
I I l I
I
Figure 1 - Format of a short-form Command Header.
7
I-----------I--------------------I--------------
---------------------- Page: 11 ----------------------
IS0 8632-3 : 1987 (E)
Overall structure
Structure of the command header
The fields in the short-form Command Header are as follows.
bits 15 to 12 element class (value range O to 15)
bits 11 to 5 element id (value range O to 127)
of parameter data that follow for this
bits 4 to O parameter list length: the number of octet
command (value range O 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 com-
mand. The presence of the value 11111 binary (decimal 31) in 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.
151413121110 9 8 7 6 5 4 3 2 1 O
_________---__-_-___---------------------------
Word 1 elem class! element id Il 11 11;
I I I I
l
I
Wrd2 I P parameter list length I
I l 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 O to 15)
bits 11 to 5 element id (value range O to 127)
bits 4 to O binary value 11111 (decimal 31) indicating long-form
Word 2
bit 15 partition flag
- O for ‘last’ partition
- 1 for ‘not-last’ partition
bits 14 to O parameter list length: the number of octets of parameter data that follow for
this command or partition (value range O 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. The parameter
type for coordinates is indicated in the Metafile Descriptor. For non-coordinate parameters, the param-
eter type is as specified in clause 5 of part 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 part 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
8
I-----------l--------------------l--------------
---------------------- Page: 12 ----------------------
IS0 8632-3 : 1987 (E)
Overall structure Structure of the command header
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 comput-
ers. 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.
or destroyed altogether if the metafile precisions are changed
This optimization may be compromised
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 O is
reserved for extension of the number of available element classes in future revisions of IS0 8632/3. It
should be treated by interpreters as any other element, as far as parsing is concerned. The next "nor-
mal" 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
revision of IS0 8632/3.
9
---------------------- Page: 13 ----------------------
IS0 8632-3 : 1987 (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 IS0 8632/1.
The primitive data forms and the symbols used to represent them are as follows.
SI Signed Integer
U1 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 sub-clauses 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
S sign bit
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 contain-
ing 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
Signed integers are represented in "two's complement" format. Four precisions may be specified for
signed integers: s-bit, 16-bit, 24-bit and 32-bit. (Integer coordinate data encoded with this primitive
data form do not use the 8-bit precision.)
5.1.1 Signed integer at 8-bit precision
Each value occupies half a metafile word (one octet).
151413121110 9 8 7 6 5 4 3 2 1 O
5.1.2 Signed integer at 16-bit precision
Each value occupies one metafile word.
151413121110 9 8 7 6 5 4 3 2 1 O
5.1.3 Signed integer at 24-bit precision
Each value straddles two successive metafile words.
10
---------------------- Page: 14 ----------------------
IS0 8632-3 : 1987 (E)
Signed integer
Primitive data forms
151413121110 9 8 7 6 5 4 3 2 1 O
O
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 %bit precision
Each value occupies half a metafile word.
151413121110 9 8 7 6 5 4 3 2 1 O
5.2.2 Unsigned integers at 16-bit precision
Each value occupies one metafile word.
151413121110 9 8 7 6 5 4 3 2 1 O
--c------------I-------------------------------
fmsb value lsbl
I I
I_______________________________________-------- I
5.2.3 Unsigned integers at 24-bit precision
Each value straddles two successive metafile words.
151413121110 9 8 7 6 5 4 3 2 1 O
---------------------- Page: 15 ----------------------
IS0 8632-3 : 1987 (E)
Unsigned integer Primitive data forms
5.3 Character
Each character is stored in an octet.
151413121110 9 8 7 6 5 4 3 2 1 O
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 sub-clause 5.2). Two precisions may be specified for Fixed Point Reals:
32-bit or 64-bit.
5.4.1 Fixed point real at 32-bit precision
Each Fixed Point Real 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.
151413121110 9 8 7 6 5 4 3 2 1 O
---______---___________________________*-------
Slmsb Mole part lsb!
Word 1
II I
1--1--_----------------------------------------- I
Word 2 lmsb Fraction part lsb!
I I
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.
151413121110 9 8 7 6 5 4 3 2 1 O
12
---------------------- Page: 16 ----------------------
IS0 8632-3 : 1987 (E)
Fixed point real
Primitive data forms
5.4.3 Value of fixed point reals
The values of the represented real numbers are given by:
for 32 bits: real-value = SI +
for 64 bits: real-value = SI +
SI stands for the “whole part” and U1 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
contains 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 ‘O), the value is positive; if ‘s’ is ‘l’,
Two precisions may be specified for Floating Point Reals: 31-bit or 64-bit. The
the value is negative.
magnitude of the value is calculated as follows for 32-bit representation.
If e = 255 and f # O, then the value is undefined.
a)
If e = 155 and f = O, then the value is as large a positive (s=O) or negative (s=1) value as possi-
b)
ble.
If O < e < 255, then the magnitude of the value is (1.f)(2e-1n).
c)
If e = O and f # O, then the magnitude of the value is (0.f)(2-12‘).
d)
If e = O and f = O, then the value is O.
e)
The magnitude of the value is calculated as follows for 64-bit representation.
If e = 2047 and f # O, then the value is undefined.
a)
If e = 2047 and f = O, then the value is as large a positive (s=O) or negative (s=l) value as pos-
b)
sible.
If O < e < 2047, then the magnitude of the value is (l.f)(2e-1m).
c)
If e = O and f # O, then the magnitude of the value is (O.f)(2-‘On).
d)
If e = O and f = O, then the value is O.
e)
5.6.1 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 fol-
lows.
sign 1 bit
exponent 8 bits
fraction 23 bits
---------------------- Page: 17 ----------------------
IS0 8632-3 : 1987 (E)
Floating point Primitive data forms
151413121110 9 8 7 6 5 4 3 2 1 O
5.5.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 fol-
lows.
sign 1 bit
exponent 11 bits
fraction 52 bits
151413121110 9 8 7 6 5 4 3 2 1 O
Word 1
Mrd 2
Word 3
Word 4
14
---------------------- Page: 18 ----------------------
IS0 8632-3 : 1987 (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 IS0 8632/1.
1)
The way the parameter type is constructed in terms of the primitive data forms, at the
2)
appropriate precisions. The precisions are those defined in clause 5 of IS0 8632/1.
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:
0
+IR, +RR, . denote the range of positive integers, range of positive reals, .<
++IR, ++RR, . denote the range of non-negative integers, range of non-negative reals, .
mI, mR . denotes ‘m’ integers, reals, .
I*, R* .
denotes an unbounded number of integers, reals, .
Combinations are used:
2R, 21, JX* 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.
15
---------------------- Page: 19 ----------------------
IS0 8632-3 : 1987 (E)
Representation of abstract parameter types
Table 1 - Representation of abstract data types.
Abstract Parameter Octets per parameter : Parameter range:
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.