EN 28632-4:1994
(Main)Information technology - Computer graphics - Metafile for the storage and transfer of picture description information -
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'
La CEI 62533:2010 s'applique aux instruments portables utilisés pour la détection et la localisation des substances radioactives émettant des photons. Ces instruments sont très sensibles, ce qui signifie qu'ils sont conçus pour détecter de faibles variations dans le domaine du bruit de fond photonique habituel, qui peuvent avoir pour origine principale un transport illicite ou des mouvements involontaires de substances radioactives. L'objet de la présente norme est d'établir des exigences d'aptitude à la fonction incluant les caractéristiques physiques, les conditions générales d'essai, les caractéristiques de rayonnement, les caractéristiques de sécurité électrique et les conditions environnementales. La présente norme fournit des exemples de méthodes d'essai acceptables, permettant de déterminer si un instrument est conforme aux exigences de la présente norme. Les résultats des essais donnent des informations aux utilisateurs sur l'aptitude des instruments de détection de rayonnement à détecter de manière fiable des sources photoniques.
Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 4: Clear text encoding (ISO/IEC 8632-4:1992)
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Information technology - Computer graphics - Metafile for the storage and transfer of picture description information - Part 4: Clear text encoding (ISO/IEC 8632-4:1992)Informationstechnik - Graphische Datenverarbeitung - Datei für die Speicherung und die Übertragung von BildinformationTechnologies de l'information - Infographie - Métafichier de stockage et de transfert des informations de description d'Information technology - Computer graphics - Metafile for the storage and transfer of picture description information -35.140Computer graphicsICS:Ta slovenski standard je istoveten z:EN 28632-4:1994SIST EN 28632-4:1997en01-december-1997SIST EN 28632-4:1997SLOVENSKI
STANDARD
SIST EN 28632-4:1997
SIST EN 28632-4:1997
SIST EN 28632-4:1997
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) SIST EN 28632-4:1997
ISO/IEC 8632-4: 1992 (E) CONTENTS Scope . . . . . . . . . . l . . Nonnative references . . . . . . . . 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 Metafile format . . . . . . . 5.1 Character repertoire . . . . 5.2 Separators . . . . . . . 5.2.1 Element separators . . . 5.2.2 Parameter separators . . 5.2.3 Comments in the metafile . 5.3 Encoding of parameter types . . 5.3.1 Integer-bound types . . 5.3.2 Real-bound types . . . 5.3.3 String-bound types . . . 5.3.4 Enumerated types . . . 5.3.5 Derived types . . . . 5.3.6 Bitstream datatype . . . 5.3.7 Structured data record operands 5.4 Forming names . . . . . . . 5.4.1 Words deleted . . . . . 5.4.2 Words added . . . . . . 5.4.3 Words used unabbreviated . 5.4.4 Abbreviations 5.4.5 The derived element names l . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . . . . . . l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * . . . . . . . . * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . * . . . 1 2 3 5 5 6 6 6 7 7 7 8 9 10 10 11 11 11 11 12 12 13 14 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 SIST EN 28632-4:1997
ISO/IEC 8632-4: 1992 (E) 6 Encoding the CGM elements . . . . . . . . . . . . . . . . . l . . 6.0.1 Comments on the element codings 6.0.2 Defaults and parameter range constraints l . . . . . . . . . . . . . #: . . . . . . . . . . . . . 6.0.3 Allowable productions in clear text metafile; . . . . . . . . . . . . . 6.1 Encoding delimiter elements . . . . . . . . . . . . . . . . . . . . 6.2 Encoding metafile descriptor elements . . . . . . . . . . . . . . . . . 6.3 Encoding picture descriptor elements . . . . . . . . . . . . . . . . . 6.4 Encoding control elements . . . . . . . . . . . . . . l . . 6.5 Encoding graphical primitive eie,,,h . . . . . . . . . . . . . . . . . 6.6 Encoding attribute elements . . . . . . . . . . . . . . . . . . . 6.7 Encoding escape elements . . . . . . . . . . . . . . . . . . . l 6.8 Encoding external elements . . . . . . . . . . . . . . . . . . . : 6.9 Encoding segment control and segment attribute elements . . . . . . . . . . . 7 Clear text encoding defaults . . . . . . . . . . . . . . . . . . . . l 8 Clear text encoding conformance . . . . . . . . . . . . . . . . . . . . A Clear text encoding-dependent formal grammar . . . . . . . . . . . . . . . B Clear text encoding example . . . . . . . . . . . . . . . . . . . . . 19 19 19 19 19 20 28 31 33 41 48 49 49 53 54 55 56 . . . 111 SIST EN 28632-4:1997
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. SIST EN 28632-4:1997
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. b . c. d . e. f . 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. 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. 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. 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. 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 SIST EN 28632-4:1997
ISO/IEC 8632-4: 1992 (E) Introduction Relationship to other International Standards 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 SIST EN 28632-4:1997
INTERNATIONAL STANDARD ISO/IEC 863204:1992 (E) 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. SIST EN 28632-4:1997
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 2022: 1986, Information processing - IS0 7-bit and &bit coded character sets - Code extension techniques. SIST EN 28632-4:1997
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 1 1 . . . = a comment (not part of the production) 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 SIST EN 28632-4:1997
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. SIST EN 28632-4:1997
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 a- - E; similarly, the following are all equivalent: 123456, $123456, 123 - -- 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 SIST EN 28632-4:1997
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- 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. SIST EN 28632-4:1997
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 *- .- -*- e,- l *- l *- l .- .*- l *- l *- -0- .- 0.- .*- I 0 + I 0 + 2~3~4~5~6~7~8~9~10~11~12~13~14~15~16 011121wu~l~171819 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 SIST EN 28632-4:1997
ISO/IEC 863294:1992 (E) Encoding of parameter types Metafile format 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- 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. Examples: 0,007,-5,+123 456 The following are equivalent: 65535,16#FFFF, 16#ffff, 8#177777,2#1111 1111 1111 1111 -32 768, -16#8000, -8#100000, -2#1000000~ OOO&kOO - The following are equivalent: - - 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 <* +> > c scaled-real number> l l - v.- c E I e > ::= I ::= is multiplied by 10 taken to the power CexponenD 8 SIST EN 28632-4:1997
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 in the case of a single-digit number may appear on either side of the radix point. It is recommended 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 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. SIST EN 28632-4:1997
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. VDC ::= I ( coordinate data, depending on VDC TYPE ::= ::= cLUV> ::= ::= cSEP> ::= K ::= I JE> { colour specifier, depending on COLOUR SELECTION MODE} ::= (if COLOUR MODEL is RGB) I 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} POINTREC ::= P l l - . .- I < > POINT in VDC space. Parentheses are optional. If they are used, they shall group 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-conforming. V l .- l .- I CR> Th
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.