ISO 8632-4:1987
(Main)Information processing systems — Computer graphics — Metafile for the storage and transfer of picture description information — Part 4: Clear text encoding
Information processing systems — Computer graphics — Metafile for the storage and transfer of picture description information — Part 4: Clear text encoding
Systèmes de traitement de l'information — Infographie — Métafichier de stockage et de transfert des informations de description d'images — Partie 4: Codage en clair des textes
General Information
Relations
Standards Content (Sample)
IS0
INTERNATIONAL STANDARD
8632-4
First edition
1987-08-01
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE DE NORMALISATION
-yF?flHAR OPrAHkl3AL&lR 00 CTAHflAPTM3AL(MW
Information processing systems - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 4 :
Clear text encoding
Systèmes de traitement de I'information - Infographie - Métafichier de stockage et de transfert
des informations de description d'images -
Partie 4 : Codage en clair des textes
Reference number
IS0 8632-4 : 1987 (E)
---------------------- Page: 1 ----------------------
Foreword
IS0 (the International Organization for Standardization) is a worldwide federation of
national standards bodies (IS0 member bodies). The work Df preparing International
Standards is normally carried out through IS0 technical committees. Each member
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
75 % approval by the member bodies voting.
least
IS0 8632-4 was prepared by Technical Committee ISO/TC 97,
International Standard
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.
O International Organization for Standardization, 1987 0
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
IS0 8632-4 : 1987 (E)
CONTENTS
O Introduction . 1
0.1 Purpose of the clear text encoding . 1
0.2 Primary objectives ; . 1
0.3 Secondary objectives . 1
0.4 Relationship to other International Standards . 1
0.5 Status of annexes . 1
...................... 2
1 Scope and field of application
2References . 3
3 Notational conventions . 4
4 Entering and leaving the metafile environment . 5
4.1 Generic clear text and instantiations . 5
4.2 Implicitly entering the metafile environment . 5
4.3 Designating and invoking the CGM coding environment from IS0 2022
....... 5
5 Metafile format . . 6
5.1 Character repertoire . . 6
5.2 Separators .
................... 7
5.2.1 Element separators . . 7
................... 7
5.2.2 Parameter separators . .
5.2.3 Comments in the metafile . . 8
5.3 Encoding of parameter types . .
................... 8
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 . . 18
5.3.5 Derived types . . 10
5.4 Forming names . . 11
5.4.1 Words deleted . . 11
5.4.2 Words added . . 11
O
.................... 11
5.4.3 Words used unabbreviated .
5.4.4 Abbreviations . . 12
5.4.5 The derived element names . 12
6 Encoding the CGM elements . 15
6.1 Allowable productions in clear text metafiles . 15
6.2 Encoding delimiter elements . 15
6.3 Encoding metafile descriptor elements . 15
6.4 Encoding picture descriptor elements . 18
6.5 Encoding control elements .
18
6.6 Encoding graphical primitive elements . 19
6.7 Encoding attribute elements . 24
6.8 Encoding escape elements . 28
6.9 Encoding external elements . 28
7 Clear text encoding defaults . 30
8 Clear text encoding conformance . 31
A Clear text encoding-dependent formal grammar . 32
B Clear text encoding example . 33
...
111
---------------------- Page: 3 ----------------------
INTERNATIONAL STANDARD IS0 8632-4 : 1987 (E)
Information processing systems - Computer graphics -
Metafile for the storage and transfer of picture
description information -
Part 4 :
Clear text encoding
O 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 Primary objectives
a. HUMAN EDITABLE: The Clear Text Encoding should be able to be hand edited or, if desired,
hand constructed.
b. HUMAN-FRIENDLY: The Clear Text Encoding should be easy and natural for people to read and
edit. Although what is easiest and most natural is a subjective judgment that varies among users,
contributing factors such as ease of recognition, ease of remembering, avoidance of ambiguity, and
prevention of mistyping have all been considered.
c. MACHINE-READABLE: The Clear Text Encoding should be able to be parsed by software.
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 DTVERSE SYSTEMS: The Clear Text Encoding should be
encoded in such a way as to maximise 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 'ïeast astonishment", this approach should minimise 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 infor-
mation density (CGM Character Encoding), these objectives are considered of secondary importance for
the CGM Clear Text Encoding.
0.4 Relationship to other Internatdonal Standards
The set of characters required to implement the Clear Text Encoding is a subset of those included in
national versions of IS0 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 part 1, 4.11.)
0.5 Status of annexes
The annexes do not form an integral part of this part of IS0 8ijR'> biit are included for information only.
1
---------------------- Page: 4 ----------------------
IS0 8632-4 : 1987 (E)
1 Scope and field of application
This part of IS0 8632/4 specifies a clear text encoding of the Computer Graphics Metafile. For each of
the elements specified in IS0 8632/1, 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.
2
---------------------- Page: 5 ----------------------
IS0 8632-4 : 1987 (E)
2 References
IS0 646, Information processing-IS0 7-bit coded character set for information interchange.
IS0 2022, Information processing-IS0 7-bd and &bit coded character sets-Code extension tech-
niques.
3
---------------------- Page: 6 ----------------------
IS0 8632-4 : 1987 (E)
3 Notational conventions
Unbracketed strings are terminals of this grammar which appear exactly, subject to the notes on
case and null characters given 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 (see IS0 8632/1
for further explanation of these items).
I*.- .-" is read as "becomes" or 'lis realized as".
= star closure (O or more occurrences).
<.>*
= plus closure (i or more occurrences).
<.>+
<.>O = optional (exactly O or i occurrences).
= parameter type x with meaning y
= exactly one of x or y
= a comment (not part of the production)
{.I
SPACES are used for readability in the grammar description; SPACES in the actual metafile are
indicated through the separator productions given below.
The metasymbols used in describing the grammar do not appear in the actual metafile.
4
---------------------- Page: 7 ----------------------
IS0 8632-4 : 1987 (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.6).
An instantiation of the Clear Text Encoding is specified by defining the character set and coding tech-
nique to be used (for example, standard national character sets based on IS0 646, non-standard charac-
ter 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 IS0 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
parties. This is suitable only if there is not to be any interchange with services using other coding tech-
niques, 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
version) IS0 646 instantiation of the CGM Clear Text Encoding may be designated and invoked from
the IS0 2022 environment by the following escape sequence:
ESC 2/5 F
where ESC is the bit combination 1/11, 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 2/5 4/0
This not only returns to the IS0 2022 coding environment, but also restores the designation and invoca-
tion of coded character sets to the state that existed prior to entering the IS0 646 CGM coding environ-
ment 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 METAFLE or after END METAFILE is undefined, and sending a picture without a
preceding BEGIN METAFLE and metafile descriptor is nonconforming interchange.
---------------------- Page: 8 ----------------------
I 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 character (also known as SLANT or SOLIDUS) or the SEMICOLON character. These charac-
ters 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 characters from the repertoire described in IS0 8632/1 (see IS0 8632/1, 4.7.6).
- Upper-case characters:
11~1, IIBII, IICII, IIDII, IIEII, IIFII, IIGII, IIHII, IlTl
,
IIJ", IIKII, IILII, IIMII, IINII, 11011, llplll llQll
) **R1)
IISII, IITII, IIUII, IIVII, IIW, II'XW, llyll, IIZII
- Lower-case characters: (see note i)
llbll, IlclIl Il$, llelll llf", IlgW ) Ilh", llill,
'*a",
Ilk", "y, llmll, II II lloll, llpll, "gll, Il II
"j " , n, r>
II II "t", lIuI1, I1 Il Ilwll, oxll, "y", Il Il
Sl v, Z
- Digits:
lloll, "111, "2", "311, "411, II~II, II~II, 11711, II~II, II~II
- I' I' (SPACE character)
- "+" (PLUS character)
- "-" (MINUS character)
- "#" (NUMBER SIGN)
- ";" (SEMICOLON character)
- "/" (SLASH, SLANT, or SOLIDUS character)
- "(" (LEFT or OPEN PARENTHESIS character)
- ")" (RIGHT or CLOSE PARENTHESIS character)
- 11,11 (COMMA character)
- "." (DECIMAL POINT or PERIOD character)
- 11111 (APOSTROPHE or SINGLE QUOTE character)
- ollll (DOUBLE QUOTE character)
-
2)
(UNDERSCORE character) (see note
'*$" (DOLLAR SIGN or CURRENCY symbol) (see note 2)
-
- **%" (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
readability of tokens.
NOTE - To illustrate: the following are all equivalent: linetype, LINETYPE, LineType, line-type, $LINETYPE,
L_I_N_E$T-Y_P_E; similarly, the following are all equivalent:
123456, $123456, 123-456, $123-456, $12$34$56.
Those control characters that are format effectors (BACKSPACE, CARRIAGE RETURN, LINEFEED,
NEWLINE, HORIZONTAL TAB, VERTICAL TAB, and FORMFEED) are permitted in the metafile,
but are treated as SPACE characters (that is, as soft delimiters) by the metafile interpreter whenever
they occur outside of a string parameter. They may be used to assist in formatting t,he metafile to
6
---------------------- Page: 9 ----------------------
IS0 8632-4 : 1987 (E)
Metafiie format Character repertoire
improve its readability. (The effect of such format effectors within string parameters is as defined in
IS0 8632/1.) A metafile written in the Clear Text Encoding is considered to be non-conforming inter-
change if it includes characters other than those listed in the repertoire and the format effectors (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 IS0 8632/4. In order to accomplish the objective of edita-
bility, it is permitted to encode the Clear Text Encoding using the character set codes native to the sys-
tem. 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 IS0 646 codes be used to encode Clear Text
metafiles for transport between diverse systems.
Null characters or format effectors 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 neces-
sary, without altering the information content of the metafile. Likewise, the two statement delimiter
characters are interchangeable and may be changed in such a translation without affecting the informa-
tion content of the metafile. The two string delimiter characters are interchangeable, but any transla-
tion shall correctly handle the possible occurrence of either string delimiter character within the string
parameter.
5.2 Separators
5.2.1 Element separators
::=
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.
as indicated by control charac-
The elements of the metafile are not terminated by the ends of records,
ters such as CR (carriage return) or LF (linefeed). Multiple elements may exist on one line, and any ele-
ment may extend over multiple lines.
5.2.2 Parameter separators
The following productions are used in the Clear Text Encoding for parameter separators:
::=
I HORIZONTAL TAB I VERTICAL TAB I FORMFEED>
::= +
::= *
::=
.- .- I
Most commands require a SOFTSEP after the element name (e.g., at least one space), This permits ele-
ment names to be formed from a mixture of alpha and numeric characters.
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 delinea tes string param-
eters, 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
7
---------------------- Page: 10 ----------------------
IS0 8632-4 : 1987 (E)
Separators Metafile format
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 s 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
SEP>; they may be replaced by a SPACE character in parsing, without affecting the meaning of the
metafile.
5.3 Encoding of parameter types
S.3.1 Integer-bound types
INTEGERS, INTEGER COORDINATES, INDICES, and the components of COLOUR DIRECT parame-
ters are all bound to signed integers, indicated in the encoding as I.
.- . .- I
::= o +
._ .-
::= o +
._ .- 2 f 3 41 5 6 I7 I 8; 9 Il0 Ill 12 f 13 I14 I15 I16
..- . .-
O Il 12; 3 14 15 16 I7 I8 19
::=
I A I B I C D I E I F I a I b I c f d I e I f
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 pre-
cedes the number with no intervening SPACE (or other ) characters allowed.
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 "O" 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-magnitude. For example, -1 would be encoded in hexadecimal as -16#1, -16#0001, etc. rather
than 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.
8
---------------------- Page: 11 ----------------------
IS0 8632-4 : 1987 (E)
Encoding of parameter types
Metafile format
Examples:
O, 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#10000000~00000000
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.
5.3.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 appropri-
ate).
::= < explicit-point number > I
< scaled-real number> I
< decimal integer >
< explicit-point number > ::= o
<
<+ *>
I
I
<* +>
>
::= < E I e >
< scaled-real number>
. .- .-
I
.- .-
as standard scientific notation (similar to
The interpretation of the scaled-real number is the same
FORTRAN "E* format), where the number represented by is multiplied by 10 taken to the
power .
There shall be at least one digit in an explicit-point number and in the body of a scaled-real number,
which in the case of a single-digit number may appear on either side of the radix point. It is recom-
mended but not 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 . No SPACE or other 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 expli-
cit 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 fractional part.
10.
For real numbers in all formats, the only permitted base of representation is base
9
---------------------- Page: 12 ----------------------
IS0 8632-4 : 1987 (E)
I
Metafiie format
Encoding of parameter types
If the ("+" or 'I-'I) 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 characters are not permitted within a number, but
characters are permitted (and have no effect on parsing).
Examples:
3.14159
7.8539823-7
271828e-5
42
-.O4321 (not recommended form)
-0.043-21
4232
5.3.3 String-bound types
a
STRING parameters 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
adjacent 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 O O FINAL "Murphy's Law: ""If it can go wrong, it will.""'*;
TEXT O O FINAL 'Murphy"s Law: "If it can go wrong, it will.'";
DATA RECORD data type is represented as a string in this encoding.
STRING parameters are indicated in the encoding as S.
6.3.4 Enumerated types
Enumerated types are bound to names, similarly to the element names. Where an implementation
wishes to support private enumerated type values, these shall be encoded as the letters "PRIV" followed e
by a string of *.
5.3.6 Derived types
In addition to the I, R, and S parameter formats, the following abbreviations are used as shorthand for
the productions shown.
VDC ::= { coordinate data, depending on VDC TYPE }
::=
K ::= I { colour value, depending on COLOUR SELECTION MODE }
POINTREC ::=
P ::= I
< >
{ COORDINATE in VDC space. Parentheses are optional. If they are used, they shall
group exactly two VDC numbers. The parenthesized form is intended to aid readability of
the metafile. If there are not two numbers in each parenthesized group, the metafile is non-
10
---------------------- Page: 13 ----------------------
IS0 8632-4 : 1987 (E)
Metafile format
Encoding of parameter types
conforming interchange. Any attempted error recovery or exception handling which a
metafile interpreter may use in this situation is neither defined nor constrained by IS0
8632/4. A metafile interpreter need not use the parentheses in parsing; in this case, they are
treated as SPACE characters rather than as NULL characters (i.e., they act as soft delim-
iters). }
V ::= I
{ Used for line width, marker size, and edge width, this parameter type depends on the
corresponding SPECIFICATION MODE element in the picture descriptor. }
5.4 Forming names
The approach was taken of selecting abbreviations for words used to name elements and enumeration
types in the CGM, and concatenating them in order.
5.4.1 Words deleted
ANNOUNCER FACTOR SPECIFICATION
AREA INDICATOR
BUNDLE REPLACEMENT
CIRCULAR SELECTION
5.4.2 Words added
INCREMENTAL
5.4.3 Words used unabbreviated
ABSTRACT END PLUS
ACTION ESCAPE POLYGON
ARC FILL PRIVATE
ARRAY FINAL REAL
BASE FONT RIGHT
BASIC HALF SCALED
BIT HATCH SET
BODY HEIGHT SIZE
BOTTOM HOLLOW SOLID
BUNDLED INDEX
START
CAP INDEmD STRING
CELL INTEGER STROKE
CHORD LEFT STYLE
CIRCLE LINE
TABLE
CLIP LIST TEXT
CLOSE
MARKER TRANSPARENCY
CODING MESSAGE TYPE
DATA METRIC UP
DEFAULTS
MODE VALUE
DIRECT NO VDC
DOWN NOT
VERSION
DRAWING
OFF WIDTH
EDGE ON 3 (numeral three)
11
---------------------- Page: 14 ----------------------
IS0 8632-4 : 1987 (E)
Metafile format
Forming names
ELLIPSE PATH
EMPTY PIE
5.4.4 Abbreviations
ABSOLUTE ABS
ALIGN
ALIGNMENT
ALTERNATE ALT
APND
APPEND
APPLICATION APPL
ASPECT SOURCE FLAG(S) ASF
AUXILIARY AUX
BACKGROUND BACK
BEGIN BEG
CENTRE CTR
CHAR
CHARACTER
a
COLOUR COLR
CONT
CONTINUOUS
CONTROL CTRL
DESC
DESCRIPTION
DIS JOINT DIS JT
8
EIGHT
ELEMENT ELEM
ELLIP
ELLIPTICAL
EXPANSION EXPAN
EXTENDED EXTD
GENERALIZED DRAWING PRIMITnrE GDP
INCREMENTAL INCR
INDMDUAL INDIV
INTERIOR INT
INVISIBLE INVIS
MAXIMUM MAX
METAFILE MF
NORMAL NORM
*
ORIENTATION OR1
PATTERN PAT
PICTURE PIC
POINT PT
POLYLINE LINE
POLYMARKER MARKER
PRECISION PREC
RECTANGLE RECT
REFERENCE REF
RESTRICTED RESTR
SCALING SCALE
SEVEN 7
SPACING SPACE
VISIBILITY VIS
VISIBLE VIS
5.4.5 The derived element names
Metafile Element Element Name Notes
BEGIN METAFILE BEGMF
END METAFILE ENDMF
12
---------------------- Page: 15 ----------------------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.