Additional Font Properties Required for Multilingual Document Interchange

by Yushi Komachi (Panasonic/MGCS, Japan)

as a Member of Committee on Multilingual IT, CICC (Center of the International Cooperation for Computerization)

Table of Contents

1. Introduction

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].

2. Existing Font Resource Architecture

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.

3. User Requirements for Multilingual and Soft Copy Documents

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.

4. Additional Font Properties and their Related Values

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.

4.1 Properties for multilingual mixed

4.1.1 Font Resource Combination Name (FONTRESCOMB)

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-name ::= STRUCTURED-NAME
                       -- ISO/IEC 9541-1//FONTRESCOMB
  fontres-value-property-list ::= (fontname-property)+

4.1.2 Alignment Position (ALIGNPOSITION)

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.

4.1.3 Property-value Lists

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.

4.2 Properties for interlinear formatting

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.

4.2.1 Ruby (RUBY)

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-glyph-complement-name, 
  ruby-glyph-complement-name ::= STRUCTURED-NAME
             -- ISO/IEC 9541-1//RUBYCOMP
  ruby-glyph-complement-value ::= "HIRAGANA-RUBY" | "KATAKANA-RUBY" |

  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-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 ::= STRUCTURED-NAME
            -- ISO/IEC 9541-1//RUBYHORALIGN
  ruby-horizontal-writing-direction-alignment-value ::= 

  ruby-vertical-writing-direction-alignment-property ::= 
  ruby-vertical-writing-direction-alignment-name ::= STRUCTURED-NAME
            -- ISO/IEC 9541-1//RYBYVERALIGN
  ruby-vertical-writing-direction-alignment-value ::= 

  ruby-line-progression-direction-offset-property ::= 
  ruby-line-progression-direction-offset-name ::= STRUCTURED-NAME
            -- ISO/IEC 9541-1//RUBYOFFSET
  ruby-line-progression-direction-offset-value ::= REL-RATIONAL

4.2.2 Proportinal Kendot (PROPKENDOT)

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-name ::= STRUCTURED-NAME
                             -- ISO/IEC 9541-1//PROPKENDOT
  proportional-kendot-value-property-list ::= 

  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 ::= 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 ::= 
              -- ISO/IEC 9541-1//PROPKENDOTOFFSET
  proportional-kendot-line-progression-direction-offset-value ::= 

4.2.3 Return Mark (RETMARK)

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-x-property ::= return-mark-offset-x-name, 
  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-name ::= STRUCTURED-NAME
            -- ISO/IEC 9541-1//RETMARKYOFFSET
  return-mark-offset-y-value ::= REL-RATIONAL

4.2.4 Added Kana (ADDEDKANA)

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-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-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-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-name ::= STRUCTURED-NAME
                    -- ISO/IEC 9541-1//ADDEDKANAYOFFSET
  added-kana-offset-y-value ::= REL-RATIONAL

4.3 Properties for color formatting

NOTE For color formatting, there should be more discussions, in particular, on font resource specific issues.

4.3.1 Design Color (DSNCOLOR)

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

5. Standardizing Strategy

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:

6. Conclusion

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.


Appendix 1: New Work Item Proposal (Draft)


Date of presentation of proposal:
National Body

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?
____ a single International Standard more than one International Standard (expected number: ........ )
____ a multi-part International Standard consisting of .......... parts
__X__ an amendment or amendments to the following International Standard(s) ....ISO/IEC 9541-1....
____ a technical report , type ...........

Relevant documents to be considered
  • ISO/IEC 9541-1, Font information interchange - Part 1: Architecture
  • AM2 to ISO/IEC 9541-1, Minor Enhancements to the Architecture to Address Font Technology Advances
  • Web Fonts, W3C Working Draft 21-July-1997
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)
  • CD: 1999-05
  • FCD: 2000-05
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....
-If yes, please specify on a separate page

Does the proposed standard concern known patented items? ....No....
- If yes, please provide full information in an annex

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:
Closing date for voting:
Signature of JTC 1 Secretary:
Lisa A. Rajchel

Appendix 2: Major specifications in Amendment 2 to ISO/IEC 9541-1 (Final Text)

From ISO/IEC JTC1/WG4 N1986

TITLE: AM2/9541-1: Minor Enhancements to the Architecture to Address Font Technology Advances
PROJECT: JTC1.18.27.1
STATUS: Approved final text
DATE: 15 May 1998
REFER TO: ISO/IEC 9541-1:1991/DAM2 and ISO/IEC JTC1/WG4 N1976 (Editing Instructions for DAM2/9541-1)

1. Scope

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.

2. Normative references

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.

3. Definitions

For the purposes of this amendment, the following definitions apply.

3.1 body size:
The font size, measured along the y axis of the glyph coodinate system.

3.2 extended body size:
A reference size with two components, measured respectively along the x and y axes of the glyph coordinate system.

3.3 design frame:
Dimensional expression that specifies the area inside which a set of glyph images can be designed.

3.4 bounding box:
Dimensional expression to specify an actual area that a glyph image occupies within a design frame.

3.5 blackness:
The ratio of the blackened area of a glyph image to the extended body size area of the glyph image.

4. Notation

The extended Backus-Naur Form (BNF) specified in ISO/IEC 9541-1 and technical corrigendum 2 to it is used.

5. Properties

5.1 Vertical Units and Horizontal Units (VUNITS, HUNITS)

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-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.

5.2 Fill Ratio (FILLRATIO)

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-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 " ".

5.3 Design Areas (DSNAREAS)

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-name ::=STRUCTURED-NAME 
                 -- ISO/IEC 9541-1//DSNAREAS
  designareas-value-property-list ::= (designarea-property |
5.3.1 Design Area (DSNAREA)

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-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.

5.4 Average ESC (AVRESC)

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-name ::=STRUCTURED-NAME  
                 -- ISO/IEC 9541-1//AVRESC
  averageesc-value-property-list ::= (averagelen-property | 
5.4.1 Average LEN (AVRLEN)

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-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.

5.5 Generalized Kendot (GENKENDOT)

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-offsetx-property ::= genkendot-offsetx-name,
  genkendot-offsetx-name ::= STRUCTURED-NAME
                             -- ISO/IEC 9541-1//GENKENDOTOFFSETX
  genkendot-offsetx-value ::= REL-RATIONAL
  genkendot-offsety-property ::= genkendot-offsety-name,
  genkendot-offsety-name ::= STRUCTURED-NAME
                             -- ISO/IEC 9541-1//GENKENDOTOFFSETY
  genkendot-offsety-value ::= REL-RATIONAL
  genkendot-thick-property ::= genkendot-thick-name,
  genkendot-thick-name ::= STRUCTURED-NAME
                             -- ISO/IEC 9541-1//GENKENDOTTHICK
  genkendot-thick-value ::= REL-RATIONAL
  genekendot-shape-property ::= genkendot-shape-name, 
  genkendot-shape-name ::= STRUCTURED-NAME
                             -- ISO/IEC 9541-1//GENKENDOTSHAPE
  genkendot-shape-value ::= STRUCTURED-NAME 
                             -- Dot Glyph Name

Appendix 3: BNF used in this paper and ISO/IEC 9541

From ISO/IEC 9541-1 and TC1/TC2 to ISO/IEC 9541-1

1. Notation

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

2. ISO/IEC 9541 Data Types

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,
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
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 ::= -- 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,]
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