GB/T 15121.4-1996
This standard is equivalent to the international standard ISO/IEC8632-4:1992 "Information technology computer graphics storage and transmission of image description information metatext volume Part 4: Clear text coding". In order to meet the needs of information processing, this standard specifies the metatext volume for storing and transmitting image description information and its clear text coding. This standard is consistent with the international standard in both technical content and format. GB/T15121, under the general title of "Information technology computer graphics storage and transmission of image description information metatext volume", includes the following parts:
Part 1: Functional description;
Part 2: Character coding,
Part 3: Binary coding;
Part 4: Clear text coding.
Appendix A of this standard is the standard appendix, and Appendix B is the indicative appendix. This standard is proposed by the Ministry of Electronics Industry of the People's Republic of China. This standard is under the jurisdiction of the Standardization Research Institute of the Ministry of Electronics Industry. This standard was drafted by Beijing University of Chemical Technology. The main drafters of this standard are Zhu Wanggui, Wang Baoai, Yu Xiaochuan and Xu Feng. 409
GB/T15121.4—1996
ISO/IEC Foreword
ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) are specialized standardization organizations worldwide. National member bodies (which are members of ISO or IEC) participate in the formulation of international standards for specific technical scopes through various technical committees established by international organizations. The technical committees of ISO and IEC cooperate in areas of common interest. Other official and non-official international organizations associated with ISO and IEC can also participate in the formulation of international standards. For the field of information technology, ISO and IEC have established a joint technical committee, namely ISO/IEC JTC1. The draft international standards proposed by the joint technical committee are circulated to national member bodies for voting. At least 75% of the voting fees of the national member bodies participating in the voting are required to publish an international standard.
International Standard ISO/IEC8632 was developed by ISO/IECJTC1 (Joint Committee on Information Technology) and approved by both ISO and IEC International Organizations.
Under the unified title "Information Technology Computer Graphics Metatext for Storage and Transmission of Graphic Description Information", ISO/IEC8632 includes the following parts:
Part 1: Functional Description;
Part 2: Character Encoding;
Part 3: Binary Encoding;
Part 4: Clear Text Encoding.
GB/T15121.4--1996
0. 1 Purpose of Clear Text Encoding
The Clear Text Encoding of Computer Graphics Metatext (CGM) provides a representation of the metatext syntax that is convenient for typing, editing and reading. It allows the metatext to be edited with any standard text editor using the internal character encoding of the host computer system. 0. 2 Main Objectives
a) Human editability. The legible text encoding should be editable by hand, or constructed by hand if necessary; b) Human friendliness. The legible text encoding should be easy and natural for a person to read and edit. Although what is easiest and most natural is a subjective judgment, factors such as ease of recognition, ease of memory, avoidance of ambiguity, and prevention of typing errors are considered. c) Machine readability. The legible text encoding should be parsable by software; d) Suitable for a wide variety of editors. The legible text encoding should not have any characteristics that make editing difficult using a regular text editor;
e) Ease of interchange between multiple systems. The legible text encoding should be encoded in such a way that the largest set of computers can use it. No assumptions should be made about factors such as character size and arithmetic modes used for metatext interpretation; f) Standard abbreviations should be used whenever possible. Standard abbreviations that have been established for other graphic standard language encodings and well-known abbreviations that have been established by widespread practice in the data processing and graphics industries should be used. Following the principle of "least surprise", the time required to learn to use this encoding should be minimized. 0.3 Secondary goals
Since the goals of other CGM encodings are to improve CPU efficiency (CGM binary encoding) and information density (CGM character encoding), these goals are also considered for CGM clear text encoding and are of secondary importance. 0.4 Relationship with other standards
The character set required to implement clear text encoding is a subset of the character set specified in GB1988. Any character set that maps from this subset can be used to implement this encoding. For some elements, CGM defines a range of values reserved for registered values, and these values and their meanings will be defined by established procedures (see 4.12 of GB/T15121.1).
1 Scope
National Standard of the People's Republic of China
Www.bzxZ.netInformation technology--Computer graphics-Metafile for storage and transferof picture description information-Part 4: Clear text encoding
GB/T 15121.4—1996
idt ISO/IEC 8632-4:1992
This standard specifies the clear text encoding of computer metafiles. For each element specified in GB/T 15121.1, it specifies the corresponding code in the clear text encoding, the allowed abbreviations, the overall format of the metafile and the comments that may be scattered in the metatext.
This encoding method of CGM allows the creation and maintenance of metafiles in a way that is easy to type, easy to edit and convenient to read. 2 Referenced standards
The clauses contained in the following standards constitute the clauses of this standard through reference in this standard. When this standard was published, the versions shown were valid. All standards are subject to revision, and parties using this standard should explore the possibility of using the latest versions of the following standards. GB1988--89 Information processing Seven-bit coded character set for information exchange (egvISO646:1983) GB2311--90 Information processing Seven-bit and eight-bit coded character set code extension technology (egvISO2022:1986) GB/T15121.1--94 Information processing system Computer graphics Metatext volume for storage and transmission of picture description information Part 1: Functional description (idtISO8632-1:1987) Registration procedures for data processing escape sequences (neqISO2375:1985) GB 12054-893
3 Notation conventions
Unbracketed strings are the terminal symbols of this syntax. As specified in this standard, they are presented as valid, clear text data streams. The bracketed strings are either nonterminal symbols (for which further productions are given), character symbol names (such as \COMMA"), or strings of the formParameters of the CGM element (see GB/T15121.1 for further explanation). "::-\ is read as "become\ or "considered to be" <.··》" = Klingon closure (0 or more occurrences) <.··> + - Klinga closure (1 or more occurrences) <.·>" - optional (0 or 1 occurrence)= parameter type X, has meaning Y= Exactly one of X or Y
(...) - a comment (not part of the production) Approved by the State Administration of Technical Supervision on December 17, 1996 412
Implemented on July 1, 1997
GB/T15121.4—1996
<...>(n) = Exactly n occurrences, n=0,1,2, SPACE is used in the syntax description to increase readability. In real metatext, spaces are represented by the separators given below. Metatext symbols used to describe the syntax do not appear in real metatext. 4 Entering and exiting the metatext environment
4.1 General clear text and examples
Clear text encodings are described in a general way that allows clear text encodings to use any character list that has the ability to express those characters enumerated in the character table (see 4.7.6 of GB/T15121.1). Examples of clear text encoding are illustrated by the character set and encoding method used (e.g., standard character sets based on GB1988, non-standard character sets such as EBCDIC, etc.). Examples of clear text encoding should be limited to the use of standard character sets based on GB1988, so that clear text encoding has the greatest possible portability between a variety of systems. This also provides an encoding that can be merged into the GB2311 text environment as a complete code to allow mixed text and graphics for applications that place high priority on human readability. 4.2 Implicit entry into the metatext environment
The clear text encoding environment can be implicitly entered using conventions between interchangeable parts. This case only applies to services that do not have any interchange using other encoding methods and is identified by conventions previously used in syntax examples. 4.3 Indicating and invoking the CGM encoding environment from GB2311 In order to be interchangeable with services using the GB2311 encoding extension method, the GB1988 standard character set examples used for CGM clear text encoding can be indicated and invoked from the GB2311 environment by the following ESC sequence: ESC2/5F
Where ESC is byte group 1/11 and F is the byte group assigned by the GB12054 registration authority. The first byte group appearing after this escape sequence will represent the beginning of a CGM metatext element or indicate a "soft delimiter" or "null character" defined below.
The following ESC sequence can be used to return to the GB2311 encoding environment: ESC2/54/0
This not only returns to the GB2311 encoding environment, but also restores the indication and invocation of the coded character set to the state that existed before the GB1988 encoding environment was entered using the ESC2/5F sequence (the terms "indication" and "invocation" are defined in GB2311). Conversion between GB2311 and metatext environments, between images in a metatext, and between metatexts is allowed. The state of the metatext interpreter and the state of the GB2311 environment are maintained separately and cannot overlap. The state of the metatext interpreter is not defined before the "metatext start" or after the "metatext end", and sending images without executing the previous "metatext start" or metatext description element is not suitable for conversion requirements.
5 Metatext format
The metatext of clear text encoding consists of a character stream of a series of elements, each element starts with an element name and ends with an element delimiter or a slash character (/ or \\) or a semicolon (,). If these characters appear within a string parameter, as defined below, they are not used as element delimiters.
5.1 Character list
In order to achieve objective e in clause 0.2), the list of characters for clear text encoding shall be limited to those enumerated below, except that the string parameter may contain any character in the list described in 4.7.6 of GB/T 15121.1 (see 4.7.6 of GB/T 15121.1). Uppercase letters:
\A\,\B\,\C\,\D\,\E\,\F\,\G\,\H\,\I\,\j\,\K\,\L\,\M\,\N\,\O\,\P\,\Q\,\R\,\S\,\T\,\U\,\\,\W\,\x\,\Y\,\z\. Lowercase letters:
GB/T 15121.4—1996
\a\,\b\,\c\,\d\,\e\,\f\,\g\,\h\,\i\,\j\,\k\ ,\}\,\m\,\n\,\o\,\p\,\q\,\r\,\s\,\t\,\u\,\y\,\w\,\x\,\y\,\2\. ——Numbers:
“0\,\1\,\2”,\3”,\4\,\5\,\6\,\7\,\g\,\g\._“” (space character).
_“+” (positive sign).
——“Two” minus sign (hyphen).
“#” (digital sign).
One “,” (semicolon).
“/\ (slash).
“(” (left parenthesis).
“)\ (right parenthesis).
“，\ (comma).
One “.” (period).
“!\ (single quotation mark or apostrophe).
_“\\ (double quotation mark).
“” (underscore).
“$” (dollar sign or currency symbol).
--"%" (percent sign).
When appearing outside of a string parameter, lowercase characters are treated the same as uppercase characters. Any combination of lowercase and uppercase letters can be used in an element or enumeration parameter name. Underscore and dollar sign are defined as "null characters" in this encoding. They can appear anywhere in the metatext. These characters (outside of string parameters) have no effect during parsing. They are valid for metatext generators and editors to improve the readability of the markup.
For example, the following are equivalent:
linetype,LINETYPE,LineType,line type,LINE$TYPE,$L-INE-T--YPE. Similarly, the following expressions are equivalent: 123456, $123456, 123456, $123-456, $12$34$56. The format control characters (BACKSPACE, CARRIAGERETURN, LINEFEED, NEWLINE, HORIZONTALTAB, VERTI-CALTAB, and FORMFEED) are permitted in metatext, but are treated as "space" characters (i.e., as soft delimiters) by the metatext interpreter whenever they appear outside of a string parameter. The use of these characters helps improve readability of the metatext format (the role of such format control characters in string parameters is as defined in ISO/IEC 15121.1). Metatext written in the clear text encoding that contains characters other than those listed above and format control characters (outside of string parameters) is considered non-conforming metatext. Extensions that require the use of characters other than those listed above and that are implementation-dependent shall be embedded in string parameters or in comments of the "escape", "message" and "application data" elements. No character encoding set is defined in this standard. In order to achieve the goal of editability, it is permitted to use the system's own character set encoding to encode clear text. It is assumed that standard conversion facilities can be used for clear text CGM metatext to translate the character set encoding of one system to another, just as other text documents that can be converted between systems. GB1988 encoding should be used to encode clear text metatext for conversion between different systems. Null characters or format control characters outside the text string that do not exist in the target system may be omitted in such translation, and lower case letters may be converted to upper case if necessary, without changing the metatext information content. Similarly, two statement delimiters may be interchanged or changed using such conversion without affecting the metatext information content. The two string delimiters are interchangeable, but any conversion should correctly handle any string delimiters that may appear in the string parameter. 414
5.2 Delimiters
5.2.1 Element delimiters
GB/T 15121.4—1996
<Terminator> - <Alternative Delimiter> <Slash|Semicolon> <Alternative Delimiter> The semicolon and slash characters are used interchangeably to delimit elements in clear text metatext. However, when they appear in a string parameter, as described below, these characters do not terminate a metatext element. The end of a record, such as CR (Carriage Return) or LF (Line Feed), controls the indicated record and does not terminate a metatext element. Several elements may appear on a line, and an element may be spread over multiple lines. 5.2.2 Parameter Delimiters
For parameter delimiters, the following productions are used in clear text encoding: Delimiter
=<Space|Carriage Return|Line FeedHorizontal Tab|Vertical Tab|Form Feed><Soft Delimiter> - <Delimiter≥
<Alternative Delimiter>=<Delimiter>
<Hard Delimiter>! 2 Optional delimiter><comma> Optional delimiter<delimiter
2 <soft delimiter><hard delimiter>
Most commands require a soft delimiter (i.e. at least one space) after the element name. This allows element names to be a mixture of letters and numbers.
The parameter delimiter between parameters is usually a delimiter. This format allows the omission of parameters (two consecutive commas mark the omission of a parameter).
Since the closing single and double quotes are sufficient to describe string parameters, and the statement delimiter "slash" separates data on both sides of it, the delimiters between these characters and adjacent parameter or element names are optional (optional delimiters). Delimiters are not allowed in a name (element name or enumeration type) or in the representation of a numeric parameter. Any number of delimiters can be used anywhere delimiters are allowed (except in string parameters). 5.2.3 Comments in metatext
Clear text Metatext can contain comments to improve readability and effectiveness. Some uses of comments are to explain changes to metatext by hand or as self-notes when reading metatext. In order to include other forms of non-graphic information in metatext, it is recommended to use the "application data" element. If it is desired to convert the clear text metatext to another form of encoding, the comments can be deleted or converted to "application data" elements. Comments are encoded as a series of printing characters and delimiters, enclosed in "%" (percent signs). The body of the comment must not include the comment delimiter "%".
Comments can be placed anywhere delimiters are used, and are equivalent to a soft delimiter, which can be replaced by space characters in grammatical analysis without affecting the meaning of the metatext itself.
5.3 Parameter type encoding
5.3.1 Integer delimited type
The components of integer, integer coordinate, index and color direct value parameters are all restricted to signed integers, and the encoding indication is I: I
<decimal integer>
<number sign>
<radix integer>
human number>
human extended number>
:=<decimal integer>! <base integer>
<number symbol>+
=<positive sign><negative sign>
=number symbol≥base≥number symbol><extended number>
::2|3|4/5/6|7|8/9/10/11/12|13/14/15/16::=0/1/213/41516/718/9
:=<number>IA|BICiD/E|Fla|blcldie|fNull characters are allowed in the value, but are not indicated in the production for simplicity. A decimal integer has an optional number symbol and at least one digit. If there is a number symbol, it must be followed by a digit, and no space (or other separator) is allowed.
GB/T 15121.4—1996
A base integer has an optional signifier, a base (an unsigned integer in the range 2 to 16 expressed in decimal), a number sign "#", and a string of one or more extension digits. If a signifier is present, it must be followed by digits, and padding with spaces (or other separators) is not allowed. The extension digits used should be valid for the named base, otherwise the metatext will be inconsistent. For example, for base 8, the digits 8, 9, etc. are invalid; for base 2, only the digits "0\ and "1" are valid, and so on. These cases are invalid for extension digits. If the signifier is omitted in any form, the value is considered non-negative. "Base and <extension digit> +" is interpreted as an unsigned number. If a minus sign appears before the digit, the final result is a negative number. Do not presuppose the word size or basic algorithms of the metatext interpreter: two's complement, two's complement, and signed numbers. For example , -1 can be encoded in hexadecimal as -16#1, 16#0001, etc., rather than 16#FFFF. Of course, the created metatext can exploit knowledge of the intended target machine, but any such assumption will limit the portability of the metatext and is therefore discouraged. Example: 0,007, 5, +123456.
The following are equivalent:
65535.16#FFFF,16#ffff,8#177777,2#1111 1111 1111 1111.
The following are equivalent:
—32768, -16#8000, -8#100000,—2#10000000000000000. Numeric delimited parameters are interpreted as "free fields", i.e., there is an implicit decimal point to the right of the rightmost digit, spaces before and after the digits are insignificant, and leading zeros are insignificant. 5.3.2 Real delimited types
Real numbers and real coordinates are restricted to real values, marked with an R in the encoding. They are written as values with an explicit decimal point or The real value of the scale (or a decimal integer where appropriate). AR>
<explicit decimal point value>
<scale real value>
<number body>
<exponent>
<exponent>「scale real value><decimal integer>!=number sign>.number>+decimal point>number>“》<<number>*<decimal point><number>+>>
=<number body>3 Comments in Metatext
Comments may be included in clear text metatext to improve readability and effectiveness. Some uses of comments are to explain changes to the metatext when manually editing it or as self-notes when reading the metatext. In order to include other forms of non-graphic information in the metatext, it is recommended to use the "application data" element. If it is desired to convert the clear text metatext to another form of encoding, the comments may be deleted or converted to "application data" elements. Comments are encoded as a series of printing characters and delimiters, enclosed in "%" (percent signs). The body of the comment must not include the comment delimiter "%".
Comments may be placed in any position where delimiters are used, and are equivalent to a soft delimiter, which can be replaced by space characters in grammatical analysis without affecting the meaning of the metatext itself.
5.3 Parameter type encoding
5.3.1 Integer delimited type
The components of integer, integer coordinate, index and color direct value parameters are all restricted to signed integers, and the encoding indication is I: I
<decimal integer>
<number sign>
<radix integer>
human number>
human extended number>
:=<decimal integer>! <base integer>
<number symbol>+
=<positive sign><negative sign>
=number symbol≥base≥number symbol><extended number>
::2|3|4/5/6|7|8/9/10/11/12|13/14/15/16::=0/1/213/41516/718/9
:=<number>IA|BICiD/E|Fla|blcldie|fNull characters are allowed in the value, but are not indicated in the production for simplicity. A decimal integer has an optional number symbol and at least one digit. If there is a number symbol, it must be followed by a digit, and no space (or other separator) is allowed.
GB/T 15121.4—1996
A base integer has an optional signifier, a base (an unsigned integer in the range 2 to 16 expressed in decimal), a number sign "#", and a string of one or more extension digits. If a signifier is present, it must be followed by digits, and padding with spaces (or other separators) is not allowed. The extension digits used should be valid for the named base, otherwise the metatext will be inconsistent. For example, for base 8, the digits 8, 9, etc. are invalid; for base 2, only the digits "0\ and "1" are valid, and so on. These cases are invalid for extension digits. If the signifier is omitted in any form, the value is considered non-negative. "Base and <extension digit> +" is interpreted as an unsigned number. If a minus sign appears before the digit, the final result is a negative number. Do not presuppose the word size or basic algorithms of the metatext interpreter: two's complement, two's complement, and signed numbers. For example , -1 can be encoded in hexadecimal as -16#1, 16#0001, etc., rather than 16#FFFF. Of course, the created metatext can exploit knowledge of the intended target machine, but any such assumption will limit the portability of the metatext and is therefore discouraged. Example: 0,007, 5, +123456.
The following are equivalent:
65535.16#FFFF,16#ffff,8#177777,2#1111 1111 1111 1111.
The following are equivalent:
—32768, -16#8000, -8#100000,—2#10000000000000000. Numeric delimited parameters are interpreted as "free fields", i.e., there is an implicit decimal point to the right of the rightmost digit, spaces before and after the digits are insignificant, and leading zeros are insignificant. 5.3.2 Real delimited types
Real numbers and real coordinates are restricted to real values, marked with an R in the encoding. They are written as values with an explicit decimal point or The real value of the scale (or a decimal integer where appropriate). AR>
<explicit decimal point value>
<scale real value>
<number body>
<exponent>
<exponent>「scale real value><decimal integer>!=number sign>.number>+decimal point>number>“》<<number>*<decimal point><number>+>>
=<number body>3 Comments in Metatext
Comments may be included in clear text metatext to improve readability and effectiveness. Some uses of comments are to explain changes to the metatext when manually editing it or as self-notes when reading the metatext. In order to include other forms of non-graphic information in the metatext, it is recommended to use the "application data" element. If it is desired to convert the clear text metatext to another form of encoding, the comments may be deleted or converted to "application data" elements. Comments are encoded as a series of printing characters and delimiters, enclosed in "%" (percent signs). The body of the comment must not include the comment delimiter "%".
Comments may be placed in any position where delimiters are used, and are equivalent to a soft delimiter, which can be replaced by space characters in grammatical analysis without affecting the meaning of the metatext itself.
5.3 Parameter type encoding
5.3.1 Integer delimited type
The components of integer, integer coordinate, index and color direct value parameters are all restricted to signed integers, and the encoding indication is I: I
<decimal integer>
<number sign>
<radix integer>
human number>
human extended number>
:=<decimal integer>! <base integer>
<number symbol>+
=<positive sign><negative sign>
=number symbol≥base≥number symbol><extended number>
::2|3|4/5/6|7|8/9/10/11/12|13/14/15/16::=0/1/213/41516/718/9
:=<number>IA|BICiD/E|Fla|blcldie|fNull characters are allowed in the value, but are not indicated in the production for simplicity. A decimal integer has an optional number symbol and at least one digit. If there is a number symbol, it must be followed by a digit, and no space (or other separator) is allowed.
GB/T 15121.4—1996
A base integer has an optional signifier, a base (an unsigned integer in the range 2 to 16 expressed in decimal), a number sign "#", and a string of one or more extension digits. If a signifier is present, it must be followed by digits, and padding with spaces (or other separators) is not allowed. The extension digits used should be valid for the named base, otherwise the metatext will be inconsistent. For example, for base 8, the digits 8, 9, etc. are invalid; for base 2, only the digits "0\ and "1" are valid, and so on. These cases are invalid for extension digits. If the signifier is omitted in any form, the value is considered non-negative. "Base and <extension digit> +" is interpreted as an unsigned number. If a minus sign appears before the digit, the final result is a negative number. Do not presuppose the word size or basic algorithms of the metatext interpreter: two's complement, two's complement, and signed numbers. For example , -1 can be encoded in hexadecimal as -16#1, 16#0001, etc., rather than 16#FFFF. Of course, the created metatext can exploit knowledge of the intended target machine, but any such assumption will limit the portability of the metatext and is therefore discouraged. Example: 0,007, 5, +123456.
The following are equivalent:
65535.16#FFFF,16#ffff,8#177777,2#1111 1111 1111 1111.
The following are equivalent:
—32768, -16#8000, -8#100000,—2#10000000000000000. Numeric delimited parameters are interpreted as "free fields", i.e., there is an implicit decimal point to the right of the rightmost digit, spaces before and after the digits are insignificant, and leading zeros are insignificant. 5.3.2 Real delimited types
Real numbers and real coordinates are restricted to real values, marked with an R in the encoding. They are written as values with an explicit decimal point or The real value of the scale (or a decimal integer where appropriate). AR>
<explicit decimal point value>
<scale real value>
<number body>
<exponent>
<exponent>「scale real value><decimal integer>!=number sign>.number>+decimal point>number>“》<<number>*<decimal point><number>+>>
=<number body>2 Real-delimited types
Real numbers and real coordinates are restricted to real values, marked with R in the encoding. They are written as values with explicit decimal points or scaled real values (or as decimal integers where appropriate). AR>
<explicit decimal value>
<scaled real value>
<number body>
<exponent>
<exponent decimal value>「scaled real value><decimal integer>!=number sign>.number>+decimal point>number>“》<<number>*<decimal point><number>+>>
=<number body>2 Real-delimited types
Real numbers and real coordinates are restricted to real values, marked with R in the encoding. They are written as values with explicit decimal points or scaled real values (or as decimal integers where appropriate). AR>
<explicit decimal value>
<scaled real value>
<number body>
<exponent>
<exponent decimal value>「scaled real value><decimal integer>!=number sign>.number>+decimal point>number>“》<<number>*<decimal point><number>+>>
=<number body><exponent>
=<explicit decimal point value>「<decimal integer>=<decimal integer>
Scaled real values are interpreted in the same way as standard scientific notation (similar to the \E\ format in FORTRAN), with the value being expressed as the exponent of 10 multiplied by the body.
In an explicit decimal point value and scaled real value, there must be at least one digit in the body, and a single digit may appear on either side of the decimal point. It is recommended, but not required, that for numbers with only a decimal portion, there be at least one digit before the decimal point. At least one digit is present. Zero can be encoded as "0.", ".0", "0.0", "0", etc., but the second representation is not recommended. In the case of scaled real values (where an E or e appears), at least one digit should appear in the exponent part. No "spaces" or separators are allowed between the body and the E or e, or between the E or e and the exponent. The interpretation of the value delimiter parameter will be "field-free", that is, if there is an explicit decimal point, it is set to the decimal point of the internal representation, regardless of the spaces before and after the decimal point, zero is valid. If the decimal point is omitted, a decimal point is provided to the right of the rightmost digit of the explicit decimal point value or to the right of the body of the scaled real value. Therefore, decimal I format values are allowed to appear in a consistent metatext and are delimited as real numbers when there is no decimal part.
In all formats, real numbers are only allowed in base 10. If the decimal sign ("ten" or "-") is omitted, the value is assumed to be non-negative. If the sign appears, it is placed immediately before the body of the number, and no spaces or other separators are allowed between the sign and the leftmost digit or between the body and the decimal point. Commas, spaces, or other separators are not allowed in a number, but null characters are allowed (and are invalid in syntax analysis). For example:
3.14159, 7.853982E—7, 271828E-5, 42, —.04321 (this format is not recommended), -0.04321, 42E2.116
5.3.3 String delimited type
GB/T 15121.4-1996
String parameters, strings (S) or fixed strings (SF) are represented by a pair of single quotes or a string within double quotes. If a single quote is required in a string delimited by single quotes, it is represented by two adjacent single quotes at that position in the string. Likewise, if a double quote is required within a character delimited by double quotes, it is represented by two adjacent double quotes. For example, the following are equivalent:
TEXT 00 FINAL\Murphy'sLaw:\\if it can go wrong,it will\\TEXT oo FINAL "Murphy\sLaw :\if it can go wrong,it will\}"Data record" data types are represented in this encoding as strings. String and data record parameters are represented in this encoding as S. Fixed strings are represented in this encoding as SF. 5.3.4 Enumerated Types
Enumerated types are restricted to names, similar to element names. 5.3.5 Derived Types
In addition to the I, R, and S parameter formats, the following abbreviations are used for abbreviations of the indicated productions:
People red, green, blue》
= 「{Coordinate data, depends on VDC type}! 2<Integer: Red><Separator>Integer: Green><Separator<Integer: Blue》! =<Integer: L><Separator><Integer: A><Separator><Integer: B><Integer: L><Separator><Integer: U><Separator><Integer: V>
=<integer:><separator<integer: magenta><separator><integer: yellow><separator><integer: black》
[Direct color>
<Point record→
<integer: A><separator><integer: B><separator><integer C>=
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.