" or " 
".
by Yushi Komachi (Panasonic/MGCS, Japan)
komachi@y-adagio.com
as a Member of Committee on Multilingual IT, CICC (Center of the International Cooperation for Computerization)
The internet services, in particular Web and email services have made it possible to interchange documents with inexpensive charge and world wide cover area. Today we can actually interchange our documents without considering any boundary between countries, at least, in the interchange operations. It resulted in a new concept of a logical territory (internet service area) where multiple languages and cultures may be observed.
In the beginning of internet days, email users described their documents defaultly in English language and ASCII coded character set. After recognized as a useful infrastructure, the internet became be expected for document interchange to be performed in creator's or recipient's mother languages.
Corresponding to those requirements, most of today's browsers can support "multilingual". Their "multilingual" functions are, however, provided by selecting an appropriate language on the menu. They should be referred to as multi-localization rather than multilingual. They cannot render such a document as contains different language parts within a page or within the document itself.
The documents interchanged in the internet logical territory are often required to be multilingual mixture, i.e., described using multiple languages within a paragraph, a page or a document. Here we will call those document as real multilingual documents. A typical example is an participant list of online meeting, where each participant should be described his own language/script.
The real multilingual documents must be rendered and represented according to appropriate multilingual formatting[1]. It means that those document should be created and treated with following considerations:
The large prevalence of web documents let user aware of the benefit of hyper documents with a number of hyperlinks between documents and documents objects. The web documents are presented and treated interactively on displays. Those soft copy documents requires new formatting schemes different from conventional hard copy documents. The formatting for soft copy documents should be based on the following display specific features[2]:
Those soft copy specific features requires different font treatments from the conventional font technology for printing.
This article focuses on the item (2) and discusses about user requirements on font technology for rendering multilingual mixture and on font properties for multilingual document interchange. Then, some new properties for soft copy presentation are discussed.
Preliminary research regarding those topics was carried out in 1997 by CICC and the activities were reported[3].
ISO/IEC JTC1/SC18 (today it is reorganized to be JTC1/SC34) developed several standards for document processing/description languages and font information interchange. They are based on an operational model[4] for document creation and interchange. Its basic concept are:
As far as font is concerned, architecture, interchange format and glyph shape representation of font resource are specified by ISO/IEC 9541 part 1, 2 and 3 respectively[5],[6],[7]. In several countries they are approved as their national standards as they are or translated, e.g., JIS X 4161, 4162 and 4163 respectively. The concept of the ISO font architecture is introduced in Web Fonts of W3C.
In general the font standards can support multilingual font treatments. For example it defines several writing modes, alignment lines, typeface design grouping, and other font properties required for multilingual mixed formatting. In actual, however, they are not enough for detailed formatting for non-Latin countries.
Japan proposed to include some additional font properties and developed Amendment 2 [8] to ISO/IEC 9541-1 with the support of international fonts experts. The status of the document is that DAM had approved and the final text was forwarded to ISO for publication. It can support some Kanji specific formatting. However, the properties defined in the AM2 still insufficient to full support of multilingual mixture.
Before the discussion of font properties, user requirements for multilingual and soft copy documents description are clarified from the font technology's point of view.
All the properties defined in this clause are optional and should be used with the required/optional properties of ISO/IEC 9541-1. The properties are described by the extended Backus-Naur Form (see Appendix 3).
NOTE Those properties should be treated only as a trigger for further discussion, since the discussions within CICC are not yet sufficient.
FONTRESNAME is a property-list to specify a font resource combination typically used in formatting the documents which contain several character repertoires.
fontrescomb-property ::= fontrescomb-name,
fontrescomb-value-property-list
fontrescomb-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//FONTRESCOMB
fontres-value-property-list ::= (fontname-property)+
ALIGNPOSITION is rel-rationals, defining the position of alignment relative to the height of body size.
alignposition-property ::= alignposition-name, alignposition-value
alignposition-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ALIGNPOSITION
alignposition-value ::= REL-RATIONAL
NOTE This property can only be applied to the writing mode whose WRMODENAME has the value of RIGHT-TO-LEFT or LEFT-TO-RIGHT.
For an actual font substitution, some property values should be listed for typical font resources. The list should includes the values of:
The property-value list should be specified as an informative annex of font resource architecture standards.
The properties of interlinear objects are basically the issue of formatting rather than font. In some systems, however, font properties for formatting hinting are effective. From this point of view, the ISO/IEC 9541-1 introduced such formatting hinting properties as Scores.
RUBY is a property-list, specifying sub-line description to associates the pronounciation or the explanation with words and phrases which in most cases consist of Kanji characters.
ruby-property ::= ruby-name, ruby-value-property-list
ruby-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBY
ruby-value-property-list ::=
(ruby-glyph-complement-property|ruby-font-size-property|ruby-formatting-type
-property|ruby-typeface-property|ruby-horizontal-writing-direction-alignment
-property|ruby-writing-vertical-direction-alignment-property|ruby-line-progr
ession-direction-offset-property)+
ruby-glyph-complement-property ::= ruby-glyph-complement-name,
ruby-glyph-complement-value
ruby-glyph-complement-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYCOMP
ruby-glyph-complement-value ::= "HIRAGANA-RUBY" | "KATAKANA-RUBY" |
"DEFAULT"
ruby-font-size-property ::= ruby-font-size-name, ruby-font-size-value
ruby-font-size-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYSIZE
ruby-font-size-value ::= "HALF"|"ONE-THIRD"
-- 1/2 | 1/3
ruby-formatting-type-property ::= ruby-formatting-type-name,
ruby-formatting-type-value
ruby-formatting-type-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYTYPE
ruby-formatting-type-value ::= "2-CHARS-RUBY"|"3-CHARS-RUBY"
ruby-typeface-property ::= ruby-typeface-name, ruby-typeface-value
ruby-typeface-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYTYPEFACE
ruby-typeface-value ::= STRUCTURED-NAME
ruby-horizontal-writing-direction-alignment-property ::=
ruby-horizontal-writing-direction-alignment-name,
ruby-horizontal-writing-direction-alignment-value
ruby-horizontal-writing-direction-alignment-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYHORALIGN
ruby-horizontal-writing-direction-alignment-value ::=
"TOP"|"CENTER"|"JUSTIFICATION"
ruby-vertical-writing-direction-alignment-property ::=
ruby-vertical-writing-direction-alignment-name,
ruby-vertical-writing-direction-alignment-value
ruby-vertical-writing-direction-alignment-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RYBYVERALIGN
ruby-vertical-writing-direction-alignment-value ::=
"CENTER"|"JUSTIFICATION"
ruby-line-progression-direction-offset-property ::=
ruby-line-progression-direction-offset-name,
ruby-line-progression-direction-offset-value
ruby-line-progression-direction-offset-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RUBYOFFSET
ruby-line-progression-direction-offset-value ::= REL-RATIONAL
PROPKENDOT is a property-list, specifying sub-line description to emphasize some characters in words and phrases. Specified symbols are filled proportionally along with characters to be emphasized.
proportional-kendot-property ::= proportional-kendot-name,
proportional-kendot-value-property-list
proportional-kendot-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//PROPKENDOT
proportional-kendot-value-property-list ::=
(proportional-kendot-symbol-property|
proportional-kendot-font-size-property|proportional-kendot-typeface-property|
proportional-kendot-line-progression-direction-offset-property)+
proportional-kendot-symbol-property ::= proportional-kendot-symbol-name,
proportional-kendot-symbol-type, kendot-symbol-value
proportional-kendot-symbol-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//PROPKENDOTSYMB
proportional-kendot-symbol-value ::= STRUCTURED-NAME
proportional-kendot-font-size-property ::=
proportional-kendot-font-size-name,
proportional-kendot-font-size-value-type,
proportional-kendot-font-size-value
proportional-kendot-font-size-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//PROPKENDOTSIZE
proportional-kendot-font-size-value-type ::= "ABS" | "RELATIVE"
proportional-kendot-font-size-value ::= REL-RATIONAL
kendot-typeface-property ::= kendot-typeface-name, kendot-typeface-value
proportional-kendot-typeface-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//PROPKENDOTTYPEFACE
proportional-kendot-typeface-value ::= STRUCTURED-NAME
proportional-kendot-line-progression-direction-offset-property ::=
proportional-kendot-line-progression-direction-offset-name,
proportional-kendot-line-progression-direction-offset-value
proportional-kendot-line-progression-direction-offset-name ::=
STRUCTURED-NAME
-- ISO/IEC 9541-1//PROPKENDOTOFFSET
proportional-kendot-line-progression-direction-offset-value ::=
REL-RATIONAL
RETMARK is a property-list, specifying sub-line description to indicate the reading sequence for Japanese interpretation of old Chinese documents.
return-mark-property ::= return-mark-name, return-mark-property-list
return-mark-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RETMARK
return-mark-property-list ::= (return-mark-offset-x-property|
return-mark-offset-y-property)*
return-mark-offset-x-property ::= return-mark-offset-x-name,
return-mark-offset-x-value
return-mark-offset-x-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RETMARKXOFFSET
return-mark-offset-x-value ::= REL-RATIONAL
return-mark-offset-y-property ::= return-mark-offset-y-name,
return-mark-offset-y-value
return-mark-offset-y-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//RETMARKYOFFSET
return-mark-offset-y-value ::= REL-RATIONAL
ADDEDKANA is a property-list, specifying sub-line description to complement the pronunciation of Kanji for Japanese interpretation of old Chinese documents.
added-kana-property ::= added-kana-name, added-kana-property-list
added-kana-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ADDEDKANA
added-kana-property-list ::=
(added-kana-font-size-property|added-kana-typeface-property|
added-kana-offset-x-property|added-kana-offset-y-property)*
added-kana-font-size-property ::= added-kana-font-size-name,
added-kana-font-size-value-type, added-kana-font-size-value
added-kana-font-size-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ADDEDKANASIZE
added-kana-font-size-value-type ::= "ABS" | "RELATIVE"
added-kana-font-size-value ::= REL-RATIONAL
added-kana-typeface-property ::= added-kana-typeface-name,
added-kana-typeface-value
added-kana-typeface-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ADDEDKANATYPEFACE
added-kana-typeface-value ::= STRUCTURED-NAME
added-kana-offset-x-property ::= added-kana-offset-x-name,
added-kana-offset-x-value
added-kana-offset-x-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ADDEDKANAXOFFSET
added-kana-offset-x-value ::= REL-RATIONAL
added-kana-offset-y-property ::= added-kana-offset-y-name,
added-kana-offset-y-value
added-kana-offset-y-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//ADDEDKANAYOFFSET
added-kana-offset-y-value ::= REL-RATIONAL
NOTE For color formatting, there should be more discussions, in particular, on font resource specific issues.
DSNCOLOR is a structured-name, the recommended color at which the font resource is designed to be displayed, according to the judgment of the design source (DSNSOURCE).
dsncolor-property ::= dsncolor-name, dsncolor-value
dsncolor-name ::= STRUCTUREDE-NAME
-- ISO/IEC 9541-1//DSNCOLOR
dsncolor-value ::= STRUCTURED-NAME
The properties are strongly requested to be approved as an international standard for open interchange of multilingual documents. For international standardizing, the following strategies are suggested:
New font properties for multilingual mixtiure and web documents are proposed to satisfy the user requirements for open interchange of multimingual documents in an internet environment. Since they are expected to be authorized as an international standard, some procedure and strategy are suggested.
Proposals and comments on font technology, in particular, regarding country stecific font properties, are welcomed and appreciated. They will be included in discussion issues for the new work items to ISO/IEC JTC1.
The author would like to express their thanks to the members of Fonts WG, Committee on Multilingual IT, CICC for valuable discussions.
PROPOSAL FOR A NEW WORK ITEM
| Date of presentation of proposal: 1998-11-01 |
Proposer: ISO/IEC JTC 1/SC 34 |
| Secretariat: National Body |
ISO/IEC JTC 1 N XXXX |
A proposal for a new work item shall be submitted to the secretariat of the ISO/IEC joint technical committee concerned with a copy to the ISO Central Secretariat.
Presentation of the proposal - to be completed by the proposer Guidelines for proposing and justifying a new work item are given in ISO Guide 26.
| Title (subject to be covered and type of standard, e.g. terminology, method of test, performance requirements, etc.) AM3/9541-1: Multilingual extensions to font resource architecture |
| Scope (and field of application) This amendment specifies additional properties of the font resources defined by ISO/IEC 9541-1. Those properties can support interchange and rendering of multilingual mixtures which are required, in particular, in web environments. |
| Purpose and justification (- attach a separate
page as annex, if necessary) Documents interchanged in the internet environments are often required to be multilingual mixture, i.e., described using multiple languages within a paragraph, a page or a document. Those multilingual documents should be rendered and represented according to appropriate multilingual formatting. Existing ISO/IEC 9541 and the Amendment can support multilingual font treatments. However, the properties defined in the standards are still insufficient to full support of multilingual mixture for multilingual formatting. |
| Programme of work
If the proposed new work item is approved , which of the
following document(s) is (are) expected to be developed? |
Relevant documents to be considered
|
| Cooperation and liaison CJK DOCP(China/Japan/Korea Document Processing Meeting), MLIT(International Symposium on the Standardization of Multilingual Information Technology) |
Preparatory work offered with target date(s)
|
| Signature: |
| Will the service of a maintenance agency or registration
authority be required? ....No.... - If yes, have you identified a potential candidate? ................ - If yes, indicate name ............................................................. Are there any known requirements for coding? ....No.... Does the proposed standard concern known patented items?
....No.... |
Comments and recommendations of the JTC 1 Secretariat - attach a separate page as an annex, if necessary
| Comments with respect to the proposal in general,
and recommendations thereon: It is proposed to assign this new item to JTC 1/SC 34 |
Voting on the proposal - Each P-member of the ISO/IEC joint technical committee has an obligation to vote within the time limits laid down (normally three months after the date of circulation).
| Date of circulation: YYYY-MM-DD |
Closing date for voting: YYY-MM-DD |
Signature of JTC 1 Secretary: Lisa A. Rajchel |
| TITLE: | AM2/9541-1: Minor Enhancements to the Architecture to Address Font Technology Advances |
| SOURCE: | WG4/RG Fonts |
| PROJECT: | JTC1.18.27.1 |
| PROJECT EDITOR: | Yushi Komachi |
| STATUS: | Approved final text |
| ACTION: | Submit to JTC1/ITTF |
| DATE: | 15 May 1998 |
| DISTRIBUTION: | |
| REFER TO: | ISO/IEC 9541-1:1991/DAM2 and ISO/IEC JTC1/WG4 N1976 (Editing Instructions for DAM2/9541-1) |
This minor enhancement specifies additional properties of the Font Resource defined by ISO/IEC 9541-1. The properties make it possible to address advances in font technology and in the increasing complexity of document processing. The properties of this amendment are optional and in addition to those defined in ISO/IEC 9541-1:1991, with the interchange format being defined in Amendment 1 to ISO/IEC 9541-2:1991.
The following standards contain provisions which, through reference in this text, constitute provisions of this amendment 2 to ISO/IEC 9541-1. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this amendment are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.
For the purposes of this amendment, the following definitions apply.
The extended Backus-Naur Form (BNF) specified in ISO/IEC 9541-1 and technical corrigendum 2 to it is used.
VUNITS and HUNITS are cardinals, the number of relative units equal to the extended body size of the font resource, as measured along the y axis and x axis respectively of the glyph coordinate system.
verticalunit-property ::= verticalunit-name, verticalunit-value
verticalunit-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//VUNITS
verticalunit-value ::= CARDINAL
horizontalunit-property ::= horizontalunit-name,
horizontalunit-value
horizontalunit-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//HUNITS
horizontalunit-value ::= CARDINAL
NOTE 1 The property RELUNITS specifies body size as measured only along the y axis of the glyph coordinate system. However, in some fonts, e.g., a certain Kanji font, dimensional references of their extended body size have to be defined in both x axis and y axis.
NOTE 2 The typical value of VUNITS should be 1000, so as to harmonize with that of RELUNITS.
FILLRATIO is a property-list, specifying a blackness of a glyph image of a reference glyph in the font resource.
fillratio-property ::= fillratio-name,
fillratio-value-property-list
fillratio-name ::=STRUCTURED-NAME
-- ISO/IEC 9541-1//FILLRATIO
fillratio-value-property-list ::= (blackness)+
blackness ::= reference-glyph, fillratio-value
reference-glyph ::= MESSAGE
-- specification of a typical glyph
fillratio-value ::= RATIONAL
-- (blackened area)x1000 /(VUNITS x HUNITS)
NOTE 3 Fill Ratio is used to determine an appropriate font substitution.
NOTE 4 In Latin fonts, "I" or "i" is used as a
reference glyph. In Japanese fonts, reference glyphs may
be " " or " ".
DSNAREAS is a property-list consisting of the property-lists that specify the design frames within which sets of glyph images are designed in their extended body sizes.
designareas-property ::= designareas-name,
designareas-value-property-list
designareas-name ::=STRUCTURED-NAME
-- ISO/IEC 9541-1//DSNAREAS
designareas-value-property-list ::= (designarea-property |
property-list)+
DSNAREA is a property-list specifying the design frame as measured by rel-rationals along the y axis and x axis in each set of glyphs. The set of glyphs configures a subset of the glyph collection of the font resource.
designarea-property ::= designarea-name,
designarea-value-property-list
designarea-name ::=STRUCTURED-NAME
-- ISO/IEC 9541-1//DSNAREA
designarea-value-property-list ::= (letter-face)+
letter-face ::= dsnarea-glyphset-name, dsnarea-height, dsnarea-width
dsnarea-glyphset-name ::= MESSAGE
-- specification of glyph-set name
dsnarea-height ::= REL-RATIONAL
-- y value of the design frame
dsnarea-width ::= REL-RATIONAL
-- x value of the design frame
NOTE 5 A glyph-set need not be a registered glyph collection.
NOTE 6 The property DSNAREA shows an extent of glyph alignment compactness in a composed line or line progression.
AVRESC is a property-list consisting of the property-lists that specify the average sizes of bounding boxes which the designed glyph shapes actually cover in their design area.
averageesc-property ::= averageesc-name,
averageesc-value-property-list
averageesc-name ::=STRUCTURED-NAME
-- ISO/IEC 9541-1//AVRESC
averageesc-value-property-list ::= (averagelen-property |
property-list)+
AVRLEN is a property-list specifying the average sizes of bounding box as measured by rel-rationals along the y axis and x axis in each set of glyphs, e.g., a katakana glyph set. The set of glyphs configures a subset of the glyph collection of the font resource.
averagelen-property ::= averagelen-name,
averagelen-value-property-list
averagelen-name ::=STRUCTURED-NAME
-- ISO/IEC 9541-1//AVRLEN
averagelen-value-property-list ::= (average-length)+
average-length ::= avrlen-glyphset-name, avrlen-height, avrlen-width
avrlen-glyphset-name ::= MESSAGE
-- specification of glyph-set name
avrlen-height ::= REL-RATIONAL
-- y value of the bounding box
avrlen-width ::= REL-RATIONAL
-- x value of the bounding box
NOTE 7 A glyph-set need not be a registered glyph collection. An average escapement of a glyph collection can be specified by the property AVGESCY or AVGESCX. The property AVRLEN can specify an average escapement of a part of the glyph collection.
NOTE 8 The property AVRLEN shows a limit of glyph alignment compactness in a composed line or line progression. The simpler functions can be provided by a-z length in Latin fonts.
NOTE 9 A relationship between VUNITS, HUNITS, DSNAREA and AVRLEN is shown in figure 5.1.
Figure 5.1 The relationship between VUNITS, HUNITS, DSNAREA and AVRLEN.
NOTE 10 The figure 5.1 illustrates only the relative positions of extended body size, design frame and bounding box.
In a simple formatting, kendots are supported by using the font property SCORE with specifying KENDOT score object. However, the property SCORE can only describe a simple dot with its specified offset and thickness.
More complicated formatting may require a particular shape for kendot. Generalized Kendot includes the capability to specify dot shape.
genkendot-property ::= genkendot-name, genkendot-value-property-list
genkendot-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//GENKENDOT
genkendot-value-property-list ::=
(genkendot-offsetx-property |
genkendot-offsety-property |
genkendot-thick-property |
genkendot-shape-property)+
genkendot-offsetx-property ::= genkendot-offsetx-name,
genkendot-offsetx-value
genkendot-offsetx-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//GENKENDOTOFFSETX
genkendot-offsetx-value ::= REL-RATIONAL
genkendot-offsety-property ::= genkendot-offsety-name,
genkendot-offsety-value
genkendot-offsety-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//GENKENDOTOFFSETY
genkendot-offsety-value ::= REL-RATIONAL
genkendot-thick-property ::= genkendot-thick-name,
genkendot-thick-value
genkendot-thick-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//GENKENDOTTHICK
genkendot-thick-value ::= REL-RATIONAL
genekendot-shape-property ::= genkendot-shape-name,
genkendot-shape-value
genkendot-shape-name ::= STRUCTURED-NAME
-- ISO/IEC 9541-1//GENKENDOTSHAPE
genkendot-shape-value ::= STRUCTURED-NAME
-- Dot Glyph Name
An extended version of Backus-Naur Form (BNF) notation is used to formally define the data types used throughout the fonts standard in a manner independent of the actual abstract data syntax used in the font interchange formats (SGML and ASN.1). By convention, basic data types are shown in uppercase.
The components of the extended BNF are:
aaa rule syntactic element
::= rule definition
| element choice (or)
& unordered conjunction (and)
, element separator
[...] optional element(s)
(...) group of elements
(...)* 0 to n repeat of element(s) in group
(...)+ 1 to n repeat of element(s) in group
"..." literal element
--... comment
The formal definition for ISO/IEC 9541 data types is given by the following BNF notation:
property ::= property-name, [property-type,] property-value
property-name ::= STRUCTURED-NAME
property-type ::= -- coded ISO/IEC 9541 data type identifier, one of:
property-list, ordered-property-list,
value-list, ordered-value-list, BOOLEAN,
STRUCTURED-NAME, MATCH-STRING, MESSAGE,
OCTET-STRING, OCTET, INTEGER, CARDINAL, CODE,
RATIONAL, REL-RATIONAL, ANGLE, PROPRIETARY-DATA
property-value ::= value | complex-value
complex-value ::= value-list | ordered-value-list |
property-list | ordered-property-list
value-list ::= (value)* -- unordered
ordered-value-list ::= (value)* -- ordered
property-list ::= (property)* -- unordered
ordered-property-list ::= (property)* -- ordered
value ::= BOOLEAN | STRUCTURED-NAME |
MATCH-STRING | MESSAGE | OCTET-STRING |
OCTET | INTEGER | CARDINAL | CODE | RATIONAL |
REL-RATIONAL | ANGLE | PROPRIETARY-DATA
BOOLEAN ::= -- a boolean value, one of TRUE or FALSE
STRUCTURED-NAME ::= -- see ISO/IEC 9070[9]
MATCH-STRING ::= -- An ordered sequence of graphic character and
possible character set control codes, of an identified
character string universal class, as specified by
ISO 8824, intended for matching
MESSAGE ::= -- An ordered sequence of graphic character and
possible character set control codes, of an identified
character string universal class, as specified by
ISO 8824, intended for matching
OCTET-STRING ::= (OCTET)*
OCTET ::= -- 8-bit byte
INTEGER ::= -- a signed integer number, -231 to 231 - 1 inclusive
CARDINAL ::= -- an unsigned integer number, 0 to 231 - 1 inclusive
CODE ::= -- a coded, unsigned integer number, 0 to 28 - 1 inclusive
RATIONAL ::= numerator [,denominator] -- denominator defaults to 1
REL-RATIONAL ::= numerator [,denominator] -- denominator defaults to value of
glyph coordinate system unit divisor or 1 if that divisor is
not defined
ANGLE ::= numerator [,denominator] -- an angle, in degrees,
0 to ±360 exclusive, rotated counter-clockwise around
the origin of the glyph coordinate system, as measured
from the positive x axis
PROPRIETARY-DATA ::= [proprietary-data-message,]
[proprietary-data-key,]
proprietary-data-blackbox
numerator ::= -- a signed integer number, -231 to 231 - 1 inclusive
denominator ::= -- a signed integer number, 1 to 231 - 1 inclusive
proprietary-data-message ::= MESSAGE
proprietary-data-key ::= OCTET-STRING
proprietary-data-blackbox ::= OCTET-STRING