ISO/IEC 8632-4:1992

INTERNATIONAL
STANDARD
Second edition
1992-l O-01
-.,.---.--
-_-._- - ._--.--.--_-. _-_----_---_.-.----------.-.---.- -------.--
Information technology - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 4:
Clear text encoding
Technologies de I’ir~formalion -- hfographie - MHaficlUer de stockage
et de fransfert des informations de description d’irnages ---
Parfie 4: Codage en c/air- des textes
Reference number
ISWI EC 8632-4: 1992(E)

---------------------- Page: 1 ----------------------
ISO/IEC 8632-4: 1992 (E)
CONTENTS
. . 1
. . . . . .
.
Scope . . . . . . . . . . l . .
. . . . . . . 2
. .
Nonnative references . . . . . . . .
. . 3
. . . . . . .
Notational conventions . . . . . . . .
. . . . . . .
. . .
Entering and leaving the metafile environment
. . . . . . .
. .
4.1 Generic clear text and instantiations . . .
. . . . . . .
. .
4.2 Implicitly entering the metafile environment
. . . . . . .
4.3 Designating and invoking the CGM coding environment from IS0 2022
. . . . 5
. . . . . . . . . . . .
. .
Metafile format . . . . . . .
l . . . . . . . . . . . 5
. . . . . .
5.1 Character repertoire . . . .
l . . l . . . . . . . . . . 6
. . . .
5.2 Separators . . . . . . .
. . 6
. . . . . . . . * . . .
. . . .
5.2.1 Element separators . . .
. . * . 6
. . . . . . . . . . . . .
.
5.2.2 Parameter separators . .
. . . 7
. . . . . . . . . . . .
. . .
5.2.3 Comments in the metafile .
. . 7
. . . . . . . . . . . . .
. . . .
5.3 Encoding of parameter types .
. . . . . . . . . . . . 7
. . . . . .
5.3.1 Integer-bound types . .
.
. . . . . . . . . . . . . . . 8
5.3.2 Real-bound types . . . . .
. . 9
. . . . . . . . . . . . . .
5.3.3 String-bound types . . . . .
. .
. . . . . . . . . . . . . 10
5.3.4 Enumerated types . . . . . .
. . 10
. . . . . . l . . . . . . .
5.3.5 Derived types . . . . . .
. . . 11
. . . . . . . . . . * . .
5.3.6 Bitstream datatype . . . l .
. . . 11
. . . . . . . . . . . . .
5.3.7 Structured data record operands .
. . . . . 11
5.4 Forming names . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 11
5.4.1 Words deleted . . . . . . . . . . . . .
. . . . . . . . * 12
5.4.2 Words added . . . . . . . . . . . . . .
. . . . . . . . . . 12
5.4.3 Words used unabbreviated . . . . . . . .
. . . . . . . . 13
5.4.4 Abbreviations . . . . . . . . . .
. . . . . . 14
5.4.5 The derived element names l . . . . . . . . . . . .
0 lSO/lEC 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.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Gekve 20 l Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
ISO/IEC 8632-4: 1992 (E)
6 Encoding the CGM elements . . . . . . . . . . . . . . . .
. l . .
19
6.0.1 Comments on the element codings . . . . . . . . . . . . . #:
19
6.0.2 Defaults and parameter range constraints l . . . . . . . . . . . .
. 19
6.0.3 Allowable productions in clear text metafile; . . . . . . . . . . . . .
19
6.1 Encoding delimiter elements . . . . . . . . . . . . . . . . . .
.
. 19
6.2 Encoding metafile descriptor elements . . . . . . . . . . . . . . . . .
20
6.3 Encoding picture descriptor elements . . . . . . . . . . . . . . . . .
28
6.4 Encoding control elements
. . . . . . . . . . . . . . l
. . 31
6.5 Encoding graphical primitive eie,,,h . . . . . . . . . . . . . . . . .
33
6.6 Encoding attribute elements . . . . . . . . . . . . . . . . . . .
41
6.7 Encoding escape elements . . . . . . . . . . . . . . . . . . . l
48
6.8 Encoding external elements . . . . . . . . . . . . . . . . . . .
49
:
6.9 Encoding segment control and segment attribute elements . . . . . . . . . . .
49
7 Clear text encoding defaults . . . . . . . . . . . . . . . . . . . .
l 53
8 Clear text encoding conformance . . . . . . . . . . . . . . . . . . . .
54
A Clear text encoding-dependent formal grammar . . . . . . . . . . . . . . .
55
B Clear text encoding example . . . . . . . . . . . . . . . . . . . . .
56
. . .
111

---------------------- Page: 3 ----------------------
ISO/IEC 8632-4: 1992 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of IS0 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. IS0 and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental 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 ISO/IEC 8632-4 was prepared by Joint Technical Committee ISO/lEC JTC 1, Information
technology.
This second edition cancels and replaces the first edition (IS0 8632-4: 1987), which has been technically revised.
ISO/IEC 8632 consists of the following parts, under the general title Information technology - Comyzrte?
graphics -Metafile for the storage and transfer ofpicture description information :
Part I: Functional specification
Part 2: Character encoding
Part 3: Binary encoding
Part 4: Clear text encoding
Annex A forms an integral part of this part of ISO/IEC 8632. Annex B is for information only.

---------------------- Page: 4 ----------------------
ISO/IEC 8632-4: 1992 (E)
Introduction
0.1 Purpose of the clear text encoding
The Clear Text Encoding of the Computer Graphics Metafile (CGM) provides a representation of the
Metafile syntax that is easy to type, edit and read. It allows a metafile to be edited with any standard text
editor, using the internal character code of the host computer system.
0.2 Primarv objectives
Y
a. Human editable: The Clear Text Encoding should be able to be hand edited or, if desired, hand con-
structed.
. Human friendly: The Clear Text Encoding should be easy and natural for people to read and edit.
b
Although what is easiest and most natural is a subjective judgment that varies among users, contribut-
ing factors such as ease of recognition, ease of remembering, avoidance of ambiguity, and prevention
of mistyping have all been considered.
Machine readable: The Clear Text Encoding should be able to be parsed by software.
c.
d . Suitable for use in a wide variety of editors: The Clear Text Encoding should not have any features
that make it difficult to edit in normal text editors.
e. Facilitate interchange between diverse systems: The Clear Text Encoding should be encoded in such
a way as to maximize the set of systems which can utilize it. No assumptions should be made as to
word size or arithmetic modes used to interpret the metafile.
f
. Use standardized abbreviations as much as possible: Where language encoding of other graphics
standards have established standard abbreviations, or where common practice in the data processing
and graphics industries has established well known abbreviations, these abbreviations are used. In
accordance with the principle of “least astonishment”, this approach should minimize the time needed
to learn to use this encoding.
0.3 Secondary objectives
Because other CGM encodings are targeted toward CPU efficiency (CGM Binary Encoding) and informa-
tion density (CGM Character Encoding), these objectives are considered of secondary importance for the
CGM Clear Text Encoding.
V

---------------------- Page: 5 ----------------------
ISO/IEC 8632-4: 1992 (E)
Relationship to other International Standards
Introduction
0.4 Relationship to other International Standards
The set of characters required to implement the Clear Text Encoding is a subset of those included in
national versions of ISO/IEC 646. Any character set that can be mapped to and from that subset may be
used to implement the encoding.
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-l) 4.12.)
Vl

---------------------- Page: 6 ----------------------
ISO/IEC 863204:1992 (E)
INTERNATIONAL STANDARD
.
Information technology - Computer graphics - Metafile for
the storage and transfer of picture description information -
Part 4 :
Clear text encoding
1 Scope
This part of ISO/IEC 8632 specifies a clear text encoding of the Computer Graphics Metafile. For each of
the elements specified in ISO/IEC 8632-l) a clear text encoding is specified. Allowed abbreviations are
specified. The overall format of the metafile and the means by which comments may be interspersed in the
metafile is specified.
This encoding of the CGM allows metafiles to be created and maintained in a form which is simple to type,
easy to edit and convenient to read.

---------------------- Page: 7 ----------------------
ISO/IEC 8632-4: 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.
ISOIIEC 644: 1991, Information technology - IS0 7-bit coded character set for information interchange.
IS0 7-bit and &bit coded character sets - Code extension techniques.
IS0 2022: 1986, Information processing -

---------------------- Page: 8 ----------------------
ISO/IEC 8632-4: 1992 (E)
3 Notational conventions
Unbracketed strings are terminals of this grammar. They appear in valid Clear Text data streams
exactly as indicated in the specifications of this part, except for allowable variations on case and null
characters described below.
Bracketed strings are either non-terminals (with further productions given), character symbol names
(such as COMMA), or parameters of the CGM element in the form cx:y> (see ISO/IEC 8632-l for
further explanation of these items).
0
. .-Tf
..- is read as “becomes” or “is realized as”.
<.>* = star closure (0 or more occurrences).
c.>+ = plus closure (1 or more occurrences).
<.>o = optional (exactly 0 or 1 occurrences).
= parameter type x with meaning y
= exactly one of x or y

. . . = a comment (not part of the production)
1 1
c.>(n) = exactly n occurrences, n=O, 1,2,. .
SPACES are used for readability in the grammar description; SPACES in the actual metafile are indi-
cated through the separator productions given below.
The metasymbols used in describing the grammar do not appear in the actual metafile.
3

---------------------- Page: 9 ----------------------
ISO/IEC 8632-4:1992 (E)
4 Entering and leaving the metafile environment
4.1 Generic clear text and instantiations
The Clear Text Encoding is described in a generic fashion that permits it to be used with any character set
capable of representing those characters enumerated in the Character Repertoire (see part 1, 4.7.3.2). An
instantiation of the Clear Text Encoding is specified by defining the character set and coding technique to
be used (for example, standard national character sets based on ISO/IEC 646, non-standard character sets
such as EBCDIC, etc).
It is recommended that an instantiation of the Clear Text Encoding bound to the standard national character
set based on ISO/IEC 646 be used in order to maximize portability of Clear Text metafiles between diverse
systems. This also provides an encoding which can be incorporated into an IS0 2022 text environment as a
complete code, to permit intermixing of text and graphics for applications which place a high priority on
human readability.
4.2 Implicitly entering the metafile environment
The Clear Text coding environment may be entered implicitly by agreement between the interchanging par-
ties. This is suitable only if there is not to be any interchange with services using other coding techniques,
and if it is known by prior agreement which instantiation of the syntax is being used.
4.3 Designating and invoking the CGM coding environment from IS0 2022
For interchange with services using the code extension techniques of IS0 2022, the (standard national vcr-
sion) ISO/IEC 646 instantiation of the CGM Clear Text Encoding may be designated and invoked from the
IS0 2022 environment by the following escape sequence:
ESC 215 F
where ESC is the bit combination l/l 1, and F refers to a bit combination that will be assigned by the IS0
Registration Authority for IS0 2375.
The first bit combination occurring after this escape sequence will then represent the beginning of a CGM
metafile element or one of the “soft separators” or “null characters” defined below.
The following escape sequence may be used to return to the IS0 2022 coding environment:
ESC 215 4/O
This not only returns to the IS0 2022 coding environment, but also restores the designation and invocation
of coded character sets to the state that existed prior to entering the ISO/IEC 646 CGM coding environment
with the ESC 2/5 F sequence. (The terms “designation” and “invocation” are defined in IS0 2022.)
It is permissable to make transitions between IS0 2022 and the metafile environment between pictures in
the metafile as well as between metafiles. The state of the metafile interpreter and the state of the IS0 2022
environment are maintained separately and not stacked. The state of the metafile interpreter before BEGIN
METAFILE or after END METAFILE is undefined, and sending a picture without a preceding BEGIN
METAFILE and metafile descriptor is nonconforming interchange.

---------------------- Page: 10 ----------------------
ISO/IEC 8632-4: 1992 (E)
5 Metafile format
A metafile in the Clear Text Encoding consists of a stream of characters forming a series of elements, each
of which starts with an element name and ends with one of the element delimiters, either the SLASH char-
acter (also known as SLANT or SOLIDUS) or the SEMICOLON character. These characters do not act as
element delimiters when occurring within the bounds of a string parameter, as defined below.
5.1 Character repertoire
In order to achieve objective (e) of sub-clause 0.2, the character repertoire of the Clear Text Encoding will
be limited to those characters enumerated below, except for string parameters, which may contain any char-
acters from the repertoire described in 4.7.3.2 ISO/IEC 8632-l.
- Upper-case characters:
“A”, “B”, “CT’, “J-J”, “E”, “F”, “G”, “H”, “I”,
‘1 J”, “~‘T, “L”, “MT’, “NT’, ‘TO”, “p”, “Q”, “R”,
l’s,‘, “T”, flu”, l’V’1, “W”, “X”, TTY”, “Z”
- Lower-case characters:
??a??, TTbTT, “CT?, T’d??, TTeTT, ‘Tf?, “g”, T’h’?, “i?‘,
“j”, “k”, “l”, ‘Tm”, ‘Tn”, ‘To”, ‘up”, ‘Tq”, ‘Tr”,
“s”, ‘Tt”, ‘TUT’, ‘TV”, ‘Tw”, ‘TX”, TTY”, ‘lz”
- Digits:
“()“, T? l?‘, “2”, “3”, “4”, “5”, “61’, “7”, “8”, “9”
- ” ” (SPACE character)
- “+” (PLUS character)
- “-” (MINUS character)
- ‘W’ (NUMBER SIGN)
- “;” (SEMICOLON character)
- “/,’ (SLASH, SLANT, or SOLIDUS character)
- “(” (LEFT or OPEN PARENTHESIS character)
- “)” (RIGHT or CLOSE PARENTHESIS character)
- “,” (COMMA character)
- “.” (DECIMAL POINT or PERIOD character)
I’ 9 0
(APOSTROPHE or SINGLE QUOTE character)
‘T ‘T 1’
(DOUBLE QUOTE character)
- “-” (UNDERSCORE character)
- “$” (DOLLAR SIGN or CURRENCY symbol)
- “%” (PERCENT SIGN character)
Lower-case characters are considered to be the same as upper-case characters, when occurring outside of
string parameters. Any combination of lower-case and upper-case characters may be used within an ele-
ment or enumerated parameter name.
The UNDERSCORE and DOLLAR SIGN symbols are defined as “null characters” within this encoding.
They may appear anywhere within the metafile, and are mandated to have no effect on parsing (outside of
string parameters). They are available for the generator or editor of the metafile to use in enhancing reada-
.
bility of tokens.
EXAMPLE - The following are all equivalent: linetype, LINETYPE, LineType, line type, SLINETYPE,
L I N E$T Y P E; similarly, the following are all equivalent: 123456, $123456, 123
a- - - -- - 456, $123 -
456, $12$34$56.
Those control characters that are format effecters (BACKSPACE, CARRIAGE RETURN, LINEFEED,
NEWLINE, HORIZONTAL TAB, VERTICAL TAB, and FORMFEED) are permitted in the metafile, but

---------------------- Page: 11 ----------------------
ISO/IEC 8632-4: 1992 (E)
Character repertoire Metafile format
are treated as SPACE characters (that is, as soft delimiters) by the metafile interpreter whenever they occur
outside of string parameters. They may be used to assist in formatting the metafile to improve its readabil-
ity. The effect of such format effecters within string parameters is as defined in ISO/IEC 8632-l.
A metafile written in the Clear Text Encoding is considered to be non-conforming if it includes characters
other than those listed in the repertoire and the format effecters (outside of string parameters).
Implementation-dependent extensions which require use of characters other than the above should be
embedded in the string parameters of the ESCAPE, MESSAGE, or APPLICATION DATA elements, or in
comments.
The code set of the characters is not fixed by this part of ISO/IEC 8632. In order to accomplish the objec-
tive of editability, it is permitted to encode the Clear Text Encoding using the character set codes native to
the system. It is presumed that standard conversion facilities can be used in translating Clear Text CGM
files from one system’s character set codes to another, consistent with the treatment of other text files being
transferred between systems. It is recommended that the ISO/IEC 646 codes be used to encode Clear Text
metafiles for transport between diverse systems.
Null characters or format effecters outside of text strings which do not exist in the target system’s encoding
may be dropped in such translation, and lower-case letters translated to upper case as necessary, without
altering the information content of the metafile. Likewise, the two statement delimiter characters are inter-
changeable and may be changed in such a translation without affecting the information content of the
metafile. The two string delimiter characters are interchangeable, but any translation shall correctly handle
the possible occurrence of either string delimiter character within the string parameter.
5.2 Separators
52.1 Element separators
(TERM> ::=
The SEMICOLON and SLASH characters may be used interchangeably to delimit elements in a Clear Text
metafile. These elements do not, however, terminate an element when they occur within a string parameter,
as described below.
The elements of the metafile are not terminated by the ends of records, as indicated by control characters
such as CR (carriage return) or LF (linefeed). Multiple elements may exist on one line, and any element
may extend over multiple lines.
52.2 Parameter separators
The following productions are used in the Clear Text Encoding for parameter separators:
-0-
l e- 1 HORIZONTAL TAB I VERTICAL TAB I FORMFEED>
l --
+
l w-
-0-
em- *
l --
we-
.*-
1
Most commands require a SOFTSEP after the element name (e.g., at least one space). This permits element
names to be formed from a mixture of alpha and numeric characters.

---------------------- Page: 12 ----------------------
ISO/IEC 8632-4: 1992 (E)
Metafile format
Separators
The separator between parameters is usually a SEP. This format permits omission of parameters. (Two
consecutive COMMAS indicate an omitted parameter.)
Since the enclosing APOSTROPHE or DOUBLE QUOTE character sufficiently delineates string parame-
ters, and the statement delimiter SLASH also sets off the data on either side of it, the separators between
these characters and adjacent parameters or element names are optional (OPTSEP).
SEPCHAR characters are not permitted within a name (element or enumerated type), or within the
representation of a numeric parameter. Any place where a SEPCHAR is permitted (other than inside a
string parameter), an arbitrary number of SEPCHARs may be used.
5.2.3 Comments in the metafile
Comments may be included in a Clear Text metafile, to enhance its readability and usefulness. Some uses
of comments might be to document hand-edited changes to the metafile, or as “notes to one’s self” made
while reading a metafile. To include other forms of nongraphical information in the metafile, it is suggested
that the APPLICATION DATA element be used. If it is desired to convert a Clear Text metafile to one of
the other encodings, comments may be either dropped or converted to APPLICATION DATA elements.
Comments are encoded as a series of printing characters and cSEPCHARX surrounded by “%” (PER-
CENT SIGN) characters. The text of the comment may not include this comment delimiter character.
Comments may be included any place that a separator may be used, and are equivalent to a cSOFTSEP>;
they may be replaced by a SPACE character in parsing, without affecting the meaning of the metafile.
5.3 Encoding of parameter types
53.1 Integer-bound types
Integers, integer coordinates, indexes, names, and the components of direct colour parameters are all bound
to signed integers, indicated in the encoding as I.
The data types UI8 and U132 of ISO/IEC 8632-l are bound to non-negative values of signed integers, also
indicated in this encoding as I.
l *-
.- I -*-
0 +
l *-
l *- I
l .-
0 +
l *-
l *- 2~3~4~5~6~7~8~9~10~11~12~13~14~15~16
-0-
.-
011121wu~l~171819
0.-
.*- cdigit>IAlBlCIDlElFla/blcldlelf
The null characters are permitted within numbers, but are not shown in the productions for simplicity.
A decimal integer has an optional sign and at least one digit. If the sign appears, it immediately precedes
the number with no intervening SPACE (or other ) characters allowed.
7

---------------------- Page: 13 ----------------------
ISO/IEC 863294:1992 (E)
Metafile format
Encoding of parameter types
A based integer has an optional sign, a base (an unsigned integer in the range 2. 16 inclusive, represented in
base lo), a “#“, and a string of one or more extended digits. If the sign appears, it immediately precedes the
number with no intervening SPACE (or other ) characters allowed. The extended digits used
shall be valid for the base named or the metafile is not conforming; e.g., for base 8 the digits “8”, “9”, etc.
are not valid, for base 2 only the digits “0” and “1” are valid, and so forth. Case is not significant for the
extended digits.
If the sign is omitted for either form, the number is considered non-negative.
Both the base and the + are interpreted as unsigned numbers, and the final result negated if
a MINUS SIGN preceded the number. No assumptions should be made as to the word size of the metafile
interpreter, or whether the underlying arithmetic is one’s complement, two’s complement, or sign-
-1 would be encoded in hexadecimal as -16#1, - 16#0001, etc. rather than
magnitude. For example,
16#FFFF. Of course, metafiles may be created utilizing prior knowledge of the intended target machine,
but any such assumptions will limit the portability of the metafile and are discouraged.
Examples:
0,007,-5,+123 456
The following are equivalent: 65535,16#FFFF, 16#ffff, 8#177777,2#1111 1111 1111 1111
The following are equivalent: -32 768, -16#8000, -8#100000, -2#1000000~ OOO&kOO -
- -
Interpretation of numerically bound parameters will be “free field”, that is, there is an implied radix point to
the right of the rightmost digit, and neither leading nor trailing spaces are significant. Leading zeroes are
not significant.
53.2 Real-bound types
Reals and real coordinates are bound to real numbers, indicated in the encoding as R. These are written as
either explicit-point numbers or scaled-real numbers (or decimal integers, where appropriate).
::= < explicit-point number > I
c scaled-real number> I
< decimal integer >
c explicit-point number > ::= 0
<
<+ *>
I
<* +>
>
l l -
c scaled-real number>
v.- c E I e >

::= I
::= The interpretation of the scaled-real number is the same as standard scientific notation (similar to FOR-
TRAN “E” format), where the number represented by is multiplied by 10 taken to the power
CexponenD
8

---------------------- Page: 14 ----------------------
ISO/IEC 8632-4: 1992 (E)
Metafile format Encoding of parameter types
There shall be at least one digit in an explicit-point number and in the body of a scaled-real number, which
It is recommended but not
in the case of a single-digit number may appear on either side of the radix point.
required that there be at least one digit before the radix point, for numbers with only a fractional part. Zero
may be encoded as “O.“, ” .O”, “O.O”, “O”, etc., although the second form is not recommended.
In the case of a scaled-real number (one where an “E” or “e” appears), at least one digit shall appear in the
characters are permitted between the and the "E"
or “e”, or between the “E” or “e” and the .
The interpretation of parameters bound to this data type will be “free field”, that is, if there is an explicit
radix point, it sets the radix point of the internal representation, and neither leading nor trailing spaces or
zeroes are significant. If the radix point is omitted, it is implied to be at the right of the rightmost digit of
the explicit-point number or of the of the scaled-real number. Thus, decimal I-format numbers are
permitted to appear in a conforming metafile for parameters bound to real numbers when there is no frac-
tional part.
For real numbers in all formats, the only permitted base of representation is base 10.
If the (“+” or “-“) is omitted, the number is assumed to be non-negative. If the sign is present, it
immediately precedes the body of the number, with no SPACE (or other ) characters allowed
between it and the leftmost digit or radix point of the body of the number.
COMMA, SPACE and other cSEPCHAR> characters are not permitted within a number, but
characters are permitted (and have no effect on parsing).
Examples:
3.14159
7.853982E-7
271828e-5
42
-.0432 1 (not recommended form)
-0.043 21
42E2 -
5.3.3 String-bound types
STRING parameters, both String (S) and String Fixed (SF) types, are represented as character strings
immediately surrounded by a matched pair of either APOSTROPHE (SINGLE QUOTE) or DOUBLE
QUOTE characters.
If an APOSTROPHE is required in a string delimited with APOSTROPHES, it is represented by two adja-
cent APOSTROPHES at that position in the string. Likewise, if a DOUBLE QUOTE character is required
in a string delimited with DOUBLE QUOTE characters, it is represented by two adjacent DOUBLE
QUOTE characters. For example, the following are equivalent
TEXT 0 0 FINAL “Murphy’s Law: ““If it can go wrong, it will.“““;
TEXT 0 0 FINAL ‘Murphy”~ Law: “If it can go wrong, it will.“‘;
DATA RECORD data type is represented as a string in this encoding.
STRING and DATA RECORD parameters are indicated in the element encodings as S. STRING FIXED is
indicated in the element encodings as SF.

---------------------- Page: 15 ----------------------
ISO/IEC 8632-4: 1992 (E)
Encoding of parameter types Metafile format
53.4 Enumerated types
Enumerated types are bound to names, similarly to the element names.
5.3.5 Derived types
In addition to the I, R, and S parameter formats, the following abbreviations are used as shorthand for the
productions shown.
::= I
VDC
( coordinate data, depending on VDC TYPE
::=
::=
cLUV> ::=

::=
cSEP>
::=
K ::= I
{ colour specifier, depending on COLOUR SELECTION MODE}
(if COLOUR MODEL is RGB)
::=
CL A B> {if COLOUR MODEL is CIELAB}
I
CL U V> {if COLOUR MODEL is CIELUV}
I
{if COLOUR MODEL is CMYK)
I
{if COLOUR MODEL is RGB-related}
I
POINTREC
::=
l l -
P
. .-
< >
I
POINT in VDC space. Parentheses are optional. If they are used, they shall group t
...