Hanzi Bitmap Font (HBF) File Format version 1.1
                                       
   In a bitmap font for Chinese or a number of other languages, each
   character takes up the same amount of space, so such fonts are often
   provided as binary files containing only bitmaps. An HBF file is a
   human-readable text file describing a font of this type, and thus
   providing a uniform interface.
   
Contents

     * HBF File Format
     * Code Schemes
     * Bounding Boxes
     * Bitmap File Format
       
Appendices

    1. Example Simple HBF File
    2. Example Full HBF File
    3. History of this Document
       
References

    1. X Logical Font Description Conventions version 1.5 [ftp: ftp.x.org
       pub/R6untarred/xc/doc/hardcopy/XLFD/xlfd.PS.Z], X Consortium
       Standard, X11R6 (1988, 1994), by Jim Flowers of Digital Equipment
       Corporation.
    2. Bitmap Distribution Format version 2.1 [ftp: ftp.x.org
       pub/R6untarred/xc/doc/hardcopy/BDF/bdf.PS.Z], X Consortium
       Standard, X11R6 (1984, 1987, 1988), by Adobe Systems, Inc.
       
HBF File Format

   An HBF file is a US-ASCII-encoded, human-readable file describing a
   bitmap font in which all characters have identical dimensions and
   offsets. The character bitmaps are stored in separate binary files.
   
   The HBF file format is based on X11 BDF [2]. An HBF file consists of a
   series of variable-length lines (terminated by carriage-return and
   linefeed or just linefeed) each beginning with a keyword consisting of
   uppercase letters, digits and underscores. Many of these are borrowed
   from BDF 2.1, and have the same meaning as there. They are described
   here for completeness. Additional keywords consist of "HBF_" followed
   by one or more English words separated by underscores. In either case,
   tokens on each input line are separated by one or more spaces.
   
   Some definitions:
     * An unsigned integer may be in either decimal, hexadecimal, or
       octal format (BDF allows only decimal numbers). An octal integer
       is introduced by the prefix "0", a hexadecimal integer by the
       prefix "0x" (as in the C programming language).
     * The bytes of an n-byte code (usually n=2) are numbered 1 to n from
       most significant to least.
       
   Lines beginning with the keyword "COMMENT" may appear anywhere in the
   file, and are ignored.
   
   Other lines appear in the following order:
    1. HBF_START_FONT formatVersion
       
       formatVersion: a token specifying the version of the HBF file
       format the file conforms to, so that backward compatibility can be
       supported even if a later version of this specification defines an
       altered format. The version described in this specification is
       1.1.
       
       Note that the X11 BDF file keyword "STARTFONT" is not used.
    2. HBF_CODE_SCHEME hanziCodeSchemeName
       
       hanziCodeSchemeName: one or more tokens representing the character
       code scheme used to index this font. See Code Schemes for possible
       values.
    3. FONT fontName
       
       fontName: one or more tokens naming the font. Case distinctions
       should be ignored in font name matching. E.g. the following all
       refer to the same font, a 24x24 bitmap Kai style font from the
       ETen system: eb5-24k, Eb5-24K, EB5-24K.
       
       For full X compatability, the font name may conform to the X11R6
       XLFD standard [1], as in the example full HBF file included as an
       appendix.
    4. SIZE ptsize xres yres
       
       A BDF entry giving the point size of the font and the x- and
       y-resolutions of the device for which it was designed. These
       values will be unused unless BDF compatability is required.
    5. HBF_BITMAP_BOUNDING_BOX w h xd yd
       
       w, h: width and height of the bounding-box of the glyph bitmap.
       
       xd, yd: the x- and y-displacement of the lower left corner of the
       glyph bitmap bounding-box from its origin.
       
       The HBF_BITMAP_BOUNDING_BOX value corresponds to the BDF 2.1
       property "BBX" for each individual glyph in a font. Since HBF is
       tailored to fonts in which all glyphs have the same size, this
       information need only be specified once.
    6. FONTBOUNDINGBOX w h xd yd
       
       w, h: width and height of the font bounding-box inside which the
       glyph bitmap of this HBF will be placed.
       
       xd, yd: the x- and y-displacement of the lower left corner of the
       font bounding-box from its origin.
       
       The relationship between HBF_BITMAP_BOUNDING_BOX and
       FONTBOUNDINGBOX is explained under Bounding Boxes.
    7. STARTPROPERTIES p
       
       p: an unsigned integer, indicating the number of font properties
       that follow this line. (Note: in BDF 2.1, this whole properties
       section is optional.)
       
       There follow p lines, each comprising a property name and a value,
       which is either an integer or a quoted string. A quoted string is
       surrounded by double quotes ("), with any internal double quote
       represented by a pair of double quotes. These properties are
       defined in the XLFD standard [1]. Those particularly relevant to
       HBF are:
          + FAMILY_NAME quotedString
            
            This identifies the "family" of typeface designs that are all
            variations of one basic typographic style. E.g., "kai-ti"
            (meaning "kai style") is a common character font style.
          + ADD_STYLE_NAME quotedString
            
            This identifies additional typographic style information that
            is not captured by other fields but is needed to identify the
            particular font. It is not a typeface classification field
            and is only used for uniqueness.
            
            For hanzi fonts, recommended values are "fantizi"
            (traditional) or "jiantizi" (simplified).
          + DEFAULT_CHAR unsignedInteger
            
            This specifies a character code to be used when an attempt is
            made to display an undefined or non-existent glyph in the
            font. An HBF file must specify this property.
          + COPYRIGHT quotedString
            
            A human-understandable quoted string that gives the copyright
            information of the legal owner of the bitmap font file(s).
            
            Any copyright information relating to the HBF file should be
            included in a COMMENT line.
          + NOTICE quotedString
            
            A human-understandable quoted string that gives the copyright
            information of the legal owner of the font design or, if not
            applicable, the trademark information for the typeface
            family.
   An example full HBF file using more XLFD properties is included as an
       appendix.
    8. ENDPROPERTIES
       
       This line indicates the end of the STARTPROPERTIES section.
    9. CHARS n
       
       n: an unsigned integer specifying the total number of the glyphs
       in this font. This BDF 2.1 property is optional in HBF, as this
       number is determined by the byte-2 and code range properties.
       (This property was mandatory in HBF 1.0.)
   10. HBF_START_BYTE_2_RANGES r
       
       r: an unsigned integer showing how many valid sub-ranges are
       represented by the byte 2 of the character codes. This section is
       present if the character code comprises 2 or more bytes.
   11. HBF_BYTE_2_RANGE rangeStart-rangeEnd
       
       rangeStart, rangeEnd: unsigned integers showing the start and the
       end value of a valid sub-range represented by the byte 2 of the
       character codes.
       
       It is required that: 0 <= rangeStart <= rangeEnd <= 0xFF. The
       sub-ranges must be given in increasing order, and must not
       overlap. E.g., there are two valid sub-ranges of byte 2 values for
       the Big5 code:

        HBF_BYTE_2_RANGE 0x40-0x7E
        HBF_BYTE_2_RANGE 0xA1-0xFE
   12. HBF_END_BYTE_2_RANGES
       
       This line indicates the end of the HBF_START_BYTE_2_RANGES
       section.
       
       The meaning and usage of "HBF_START_BYTE_3_RANGES",
       "HBF_BYTE_3_RANGE" and "HBF_END_BYTE_3_RANGES" are similar to
       those for "byte 2".
   13. HBF_START_CODE_RANGES r
       
       r: an unsigned integer showing how many code-ranges of character
       code are valid in the whole coding space of the font.
   14. HBF_CODE_RANGE firstCode-lastCode bitmapFileName offset
       
       firstCode, lastCode: unsigned integers showing the first and the
       last character code of a valid code range of the coding space of
       the HBF. For a 2-byte character code, it is required that: 0 <=
       firstCode <= lastCode <= 0xFFFF. The code ranges must be given in
       increasing order, and must not overlap.
       
       bitmapFileName: an unquoted string of the name of the bitmap file
       containing the bitmaps for the characters in the code range. The
       form of the file name will depend on the native operating system,
       as will its interpretation. However, in most implementations the
       bitmap file name will be interpreted as if the current directory
       were the one containing the HBF file.
       
       offset: an unsigned integer (at least 32-bits) representing the
       file offset of the bitmap of the character code firstCode in the
       bitmap file.
       
       See Bitmap File Format for more details on how byte-2 ranges and
       code ranges describe the structure of the bitmap files.
   15. HBF_END_CODE_RANGES
       
       This line indicates the end of the HBF_START_CODE_RANGES section.
   16. HBF_END_FONT
       
       This line marks the end of the HBF file. Note that the X11 BDF
       file keyword "ENDFONT" is not used.
       
Code Schemes

   Code schemes are named by one or more tokens. Case is to be ignored in
   matching these names. GB, JIS and KSC code schemes may be either
   Graphic Left (GL) or Graphic Right (GR) encoded, but GL encoding
   should be used if consistency with the X11R6 distribution [ftp:
   ftp.x.org pub/R6untarred/xc/fonts/bdf/misc] is desired.
   
   Accepted values for HBF_CODE_SCHEME in this specification are:
   
   GB2312-1980
          not simply "GB", nor "GB2312". there are many GuoBiao's for
          hanzi.
          
   Big5
          any so-called "Big5" bitmap file(s) can be used, but such
          bitmap file(s) must conform to the Big5 character code standard
          without vendor-added character code. The Big5 character code
          scheme has the following valid code ranges for hanzi:
          

        0xA440-0xC67E for frequently-used hanzi      (5401 chars)
        0xC940-0xF9D5 for less-frequently-used hanzi (7652 chars)

   Big5 ETen 3.10
          not simply "Big5"; use specifically the bitmap files in the
          ETen system 3.10 which contains vendor-specific character
          codes.
          
          Similar specification of other vendors and software versions
          are acceptable, to provide a more accurate description.
          
   CNS11643-92p1 to CNS11643-92p7
          Chinese National Standard of ROC, containing 7 planes.
          
   Unicode 1.1
          version "1.1", equivalent to ISO/IEC 10646-1 UCS-2, level 3.
          Perhaps there will be vendor-specific versions at a later date.
          
   JISX0208-1990
          Japanese Industrial Standard
          
   KSC5601-1987
          Korean Standard Code (formingly KIPS)
          
   Any additional coding schemes should be discussed on the mailing list
   "soft-authors@ifcss.org".
   
Bounding Boxes

   A bounding box is shown below.

                |<--- width --->|
                      = w
              - ----------------- -
              ^ |   |           | ^
              | |   |           | |
       ascent | |   |           | |
              | |   |           | | height = h
              | |   |           | |
baseline ---> - |---O-----------| |             point "O" = Origin
              | |   |           | |
 descent = yd | |   |           | |
              v |   |           | v
              - ----------------- -



                |<--|
                  xd

   The values are in pixels of the bitmap. In the fixed pitch fonts that
   HBF deals with, these parameters will be the same for each character
   of the font.
   
   The HBF_BITMAP_BOUNDING_BOX bounds the bitmap of a glyph; thus its
   width and height are equal to the width and height of the bitmap.
   
   FONTBOUNDINGBOX is a BDF 2.1 property, defining an area within which
   all glyphs of the font are usually displayed (even if the font is of
   variable width). In HBF, the FONTBOUNDINGBOX allows for the
   specification of inter-glyph and inter-line spacing. In many cases,
   where such control over spacing is not required, the sizes of
   HBF_BITMAP_BOUNDING_BOX and FONTBOUNDINGBOX are the same. In all
   cases, the bitmap bounding box must fit within the font bounding box.
   
   In an application, a line of text may contain glyphs from more than
   one font. The glyphs must be aligned along the horizontal "baseline"
   of the line of text. The baseline contains the "origins" of the glyph
   bounding boxes. The origin of a bounding box may not be at the lower
   left corner of the bounding box because some letters in a Latin font,
   like 'g', 'j', 'Q', etc., have "descenders" extending below the
   baseline. The xd and yd values of a bounding box specify the offset of
   the lower left corner of the bounding box from the origin.
   
   In such cases, the yd value of both bounding boxes may be non-zero due
   to the need to align neatly with a Latin font along a line of text.
   E.g., use

          FONTBOUNDINGBOX 24 24 0 -4

   instead of

          FONTBOUNDINGBOX 24 24 0 0

   to align with a Latin font with "FONTBOUNDINGBOX 12 24 0 -4" which
   contains letters with descent "-4", such as 'g', 'j', 'Q', etc.
   
   The following shows an example of unequal bitmap and font bounding
   boxes. Suppose the HBF file contains the lines

          FONTBOUNDINGBOX 16 18 0 -2

   and (indicating a 16x15 bitmap)

          HBF_BITMAP_BOUNDING_BOX 16 15 0 -1

   In the following diagram, the boundary of the font bounding box is
   dashed, while the boundary of the bitmap bounding box is dotted:

                |<--- width --->|
                      = 16
                -----------------      -
a blank row-->  |               |      ^
a blank row-->  |               |      |
                |...............| -    |
                |///////////////| ^    |
                |///////////////| |    |
                |// 16x15  /////| |    |
                |// bitmap /////| |15  |18 = FONTBOUNDINGBOX height.
                |///////////////| |    |
                |///////////////| |    |
baseline ---->  O---------------- |    |   point "O" = Origin (0,0)
                |///////////////| v    |
              -1|...............| -    |   -1 = yd of HBF_BITMAP_BOUNDING_BOX.
a blank row-->  |               |      v
              -2-----------------      -   -2 = yd of FONTBOUNDINGBOX.

   Note that the origins of the two bounding boxes are identified.
   
   The following are some more examples to illustrate the relationships
   between FONTBOUNDINGBOX and HBF_BITMAP_BOUNDING_BOX.
   
   Suppose we have five HBF files: HBF1, HBF2, HBF3, HBF4, HBF5.
   
  16x16 bitmap HBFs
  
   HBF1: (HBF_BITMAP_BOUNDING_BOX and FONTBOUNDINGBOX are the same.)

HBF_BITMAP_BOUNDING_BOX 16 16 0 -2
FONTBOUNDINGBOX         16 16 0 -2

   HBF2: (to allow for inter-line spacing of 2 pixels with the glyph
   bitmap aligned at the bottom of the FONTBOUNDINGBOX)

HBF_BITMAP_BOUNDING_BOX 16 16 0 -2
FONTBOUNDINGBOX         16 18 0 -2

  16x15 bitmap HBFs
  
   HBF3: (to be aligned at the top of HBF1 glyph bitmap when shown with
   HBF1)

HBF_BITMAP_BOUNDING_BOX 16 15 0 -1
FONTBOUNDINGBOX         16 16 0 -2

   HBF4: (to be aligned at the bottom of HBF1 glyph bitmap when shown
   with HBF1)

HBF_BITMAP_BOUNDING_BOX 16 15 0 -2
FONTBOUNDINGBOX         16 16 0 -2

   HBF5: (to be aligned at the top of HBF2 glyph bitmap when shown with
   HBF2 and using the same FONTBOUNDINGBOX as HBF2)

HBF_BITMAP_BOUNDING_BOX 16 15 0 -1
FONTBOUNDINGBOX         16 18 0 -2

Bitmap File Format

   A "bitmap file" is a binary file of character bitmaps indexed by the
   corresponding HBF file. The format described below is fairly common;
   in particular many bitmap fonts supplied by vendors may be used
   without modification.
   
  Structure of a Bitmap
  
   A bitmap of size "Width x Height" bits is stored by rows from top to
   bottom, with each row taking up a whole number of bytes. Thus each row
   occupies (Width+7)/8 bytes, where integer division with truncation of
   decimal places is used in the calculation. Each row is stored from
   left to right, with the leftmost pixel in the most significant bit of
   the first byte. Hence each bitmap occupies Height*((Width+7)/8) bytes.
   For example,
     * a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes
     * a 15x16 bitmap occupies 16*((15+7)/8) = 32 bytes
     * a 16x15 bitmap occupies 15*((16+7)/8) = 30 bytes
     * a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes
       
   A bit value of 1 represents part of the character, while a value of 0
   indicates the background.
   
  Arrangement of Bitmaps in the File
  
   Each HBF_CODE_RANGE entry in the HBF file gives an offset into a
   bitmap file at which the bitmaps for a range of characters may be
   found. The bitmaps for characters from firstCode to lastCode are
   stored sequentially in the file, but bitmaps for codes outside the
   defined byte-2 range are omitted.
   
   For example, suppose we have a 24x24 Big5 font, so that each bitmap
   occupies 72 bytes. In Big5, the ranges for the second byte are:

        HBF_BYTE_2_RANGE 0x40-0x7E
        HBF_BYTE_2_RANGE 0xA1-0xFE

   An entry of the form

        HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0

   means that the offsets of bitmaps in the file are

             0  bitmap for character A440
            72  bitmap for character A441
           ...  ...
          4464  bitmap for character A47E
          4536  bitmap for character A4A1
           ...  ...
         11232  bitmap for character A4FE
         11304  bitmap for character A540
          ...   ...
        395568  bitmap for character C67E

Example Simple HBF File

   The following is an example simple HBF file which uses the bitmap
   files supplied in the ETen system Version 3.10.

HBF_START_FONT 1.1
HBF_CODE_SCHEME Big5 ETen 3.10
FONT eb5-24k
SIZE 24 72 72
HBF_BITMAP_BOUNDING_BOX 24 24 0 -2
FONTBOUNDINGBOX 24 24 0 -2
COMMENT  Begin Logical Font Description -- 5 special properties for this FONT
STARTPROPERTIES 5
FAMILY_NAME "Kai"
ADD_STYLE_NAME "fantizi"
DEFAULT_CHAR 0xA140
COMMENT Public domain simple HBF file (1993)
COMMENT The following lines relate to the bitmaps and typeface
COPYRIGHT "(c) 1988, 1992 ETen Information System Corp"
NOTICE "The bitmap files are that of ETen system 3.10 or the equivalent."
ENDPROPERTIES
COMMENT  CHARS is optional in HBF
CHARS 13943
HBF_START_BYTE_2_RANGES 2
HBF_BYTE_2_RANGE 0x40-0x7E
HBF_BYTE_2_RANGE 0xA1-0xFE
HBF_END_BYTE_2_RANGES
COMMENT
HBF_START_CODE_RANGES 4
HBF_CODE_RANGE 0xA140-0xA3E0 spcfont.24 0
HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0
HBF_CODE_RANGE 0xC6A1-0xC8FE spcfsupp.24 0
HBF_CODE_RANGE 0xC940-0xF9FE stdfont.24k 388872
HBF_END_CODE_RANGES
COMMENT
COMMENT  Non-hanzi symbol (441 chars) bitmaps in file "spcfont.24".
COMMENT  Vendor-specific symbols (408 chars) bitmaps in file "spcfsupp.24k".
COMMENT  Frequently-used hanzi (5401 chars) bitmaps followed by
COMMENT  less-frequently-used hanzi (7693 chars) bitmaps in file "stdfont.24k".
COMMENT
COMMENT  For the fourth HBF_CODE_RANGE of less-frequently-used hanzi,
COMMENT  the range is smaller in standard Big5: 0xC940-0xF9D5 (7652 chars);
COMMENT  and the offset 388872 bytes from the start of the file "stdfont.24k"
COMMENT  is based on the information supplied by
COMMENT  Stephen G. Simpson <simpson@math.psu.edu>
COMMENT  -- these may vary depending on the version of the ETen system.
HBF_END_FONT

Example Full HBF File

   The following is an example full HBF file which uses the bitmap files
   supplied in the ETen System Version 3.10.

HBF_START_FONT 1.1
HBF_CODE_SCHEME Big5 ETen 3.10
FONT eb5-24k
COMMENT
COMMENT An equivalent full XLFD 1.5 conforming font name is
COMMENT -ETen-Kai-medium-r-normal-fantizi-24-240-75-75-c-240-Big5.ETen.3.10-1
COMMENT which is formed from the first 15 properties listed in
COMMENT the STARTPROPERTIES section below.
COMMENT Any of these properties is optional, as in the simple HBF file.
COMMENT Modified by cyl@ifcss.org 1994.7.16
COMMENT
SIZE 24 72 72
HBF_BITMAP_BOUNDING_BOX 24 24 0 -2
FONTBOUNDINGBOX 24 24 0 -2
COMMENT
COMMENT  Begin Logical Font Description -- 20 special properties for this FONT
COMMENT
STARTPROPERTIES 20
FONTNAME_REGISTRY ""
FOUNDRY "ETen"
FAMILY_NAME "Kai"
WEIGHT_NAME "medium"
SLANT "r"
SETWIDTH_NAME "normal"
ADD_STYLE_NAME "fantizi"
PIXEL_SIZE 24
POINT_SIZE 240
RESOLUTION_X 75
RESOLUTION_Y 75
SPACING "c"
AVERAGE_WIDTH 240
COMMENT '-' can't be used in full XLFD name, thus use '.' in CHARSET_REGISTRY
CHARSET_REGISTRY "Big5.ETen.3.10"
CHARSET_ENCODING "1"
FONT_ASCENT 22
FONT_DESCENT 2
COMMENT
COMMENT  All the above properties are discussed in XLFD Conventions 1.5.
COMMENT
COMMENT  The rest is the same as the simple HBF file.
COMMENT
DEFAULT_CHAR 0xA140
COMMENT 0xA140 is the Space character.
COPYRIGHT "(c) 1988, 1992 ETen Information System Corp"
NOTICE "The bitmap files are that of ETen System 3.10 or the equivalent."
ENDPROPERTIES
COMMENT Users should observe the copyright of the individual bitmap font files.
COMMENT This HBF header file is in the public domain (1994)
COMMENT
COMMENT  CHARS is optional in HBF
CHARS 13943
HBF_START_BYTE_2_RANGES 2
HBF_BYTE_2_RANGE 0x40-0x7E
HBF_BYTE_2_RANGE 0xA1-0xFE
HBF_END_BYTE_2_RANGES
HBF_START_CODE_RANGES 4
HBF_CODE_RANGE 0xA140-0xA3E0 spcfont.24 0
HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0
HBF_CODE_RANGE 0xC6A1-0xC8FE spcfsupp.24 0
HBF_CODE_RANGE 0xC940-0xF9FE stdfont.24k 388872
HBF_END_CODE_RANGES
COMMENT 0xA140-0xA3E0 is 408 Big5 specific punctuation, numerals,
COMMENT                  Roman, Greek, Bopomofo Alphabet and 33
COMMENT                  Control characters
COMMENT 0xA440-0xC67E is 5401 frequently used Big5 Chinese
COMMENT                  characters.
COMMENT 0xC6A1-0xC8FE is 408 ETen specific numerals, Japanese and
COMMENT                  Russian alphabets, etc.
COMMENT 0xC940-0xF9FE is 7652 less frequently used Big5 Chinese
COMMENT                  characters and 41 other ETen specific
COMMENT                  characters.
HBF_END_FONT

History of this Document

   Version 1.0 [ftp: ifcss.org
   software/fonts/hbf-discussion/HBF_std_v1.0] of this document was
   written by Man-Chi Pong, as a result of discussion via e-mail among a
   group of Chinese software developers who would like to see a standard
   way to access hanzi (Chinese character) bitmap files. The following is
   a list, in alphabetic order of the surnames, of the contributors to
   the discussion.

CAI@neurophys.wisc.edu                  (CAI,     Yidao)
jiang@ifcss.org                         (JIANG,   Yuan)
lee@umunhum.stanford.edu                (LEE,     Fung Fung)
A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT     (LEMBERG, Werner)
87P0786@csdvax.csd.unsw.edu.au          (NI,      Hongbo)
mcpong@cs.ust.hk                        (PONG,    Man-Chi)
simpson@math.psu.edu                    (SIMPSON, Stephen G.)
tee@ecf.toronto.edu                     (TEE,     Luns)
yawei@bronze.ucs.indiana.edu            (WEI,     Ya-Gui)
eric@coeus.ucsd.edu                     (YANG,    Bo)
Ricky.Yeung@eng.sun.com                 (YEUNG,   Ricky)
FARZ%NMUMUS.bitnet@vmd.cso.uiuc.edu     (ZHANG,   Roxin)
ygz@cs.purdue.edu                       (ZHANG,   Yongguang)

   All previous mail exchanges, related programs, the names in the
   mailing list (soft.list), etc., are ftp'able [ftp: ifcss.org
   software/fonts/hbf-discussion/].
   
   The following revisions culminated in version 1.0:
   
   Draft 0.1 (1993/02/17)
          
   Draft 0.2 (1993/02/28)
          
          + All property keywords related to HBF starts with "HBF_".
          + "_" is used to separate the English words in the HBF keywords
            to make them more readable.
          + "ENCODING" is renamed as "HBF_CODE_SCHEME" because "ENCODING"
            in X BDF means the hanzi code value of a glyph.
          + "SEGMENT" is renamed as "HBF_CODE_RANGE"; more suggestive.
            
   Draft 0.3 [ftp: ifcss.org
          software/fonts/hbf-discussion/HBF_std_v1.0_d0.3] (1993/03/15)
          
          + uniform naming of keywords: HBF_xxx_yyy.
          + cut the details of X11R5 XLDF and BDF properties.
          + simplify API.
            
   Draft 0.4 [ftp: ifcss.org
          software/fonts/hbf-discussion/HBF_std_v1.0_d0.4] (1993/04/30)
          
          + found in BDF [2] that " can be used in a string (use "").
          + FONTBOUNDINGBOX & HBF_BITMAP_BOUNDING_BOX can have -ve xd yd;
            BNF in Appendix 1 updated.
          + changes in API HBF_OpenFont() HBF_GetBitmap() and API
            routines return 0 if OK, non-zero if not OK.
            
   Draft 0.5 [ftp: ifcss.org
          software/fonts/hbf-discussion/HBF_std_v1.0_d0.5] (1993/05/28)
          
          + mention that HBF file name convention is not part of this
            standard.
          + some minor presentation changes.
            
   Adopted as version 1.0.
          
   The revisions leading to version 1.1 were coordinated by Nelson Chin
   (Chen Yilong) with contributions from:

CAI@neurophys.wisc.edu                  (CAI,     Yidao)
A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT     (LEMBERG, Werner)
rap@doc.ic.ac.uk                        (PATERSON, Ross)

   The revisions culminated as version 1.1 are:
   
   Draft 1.01 (1994/07/19)
          
          + all references to X11R5 changed to X11R6. [cyl@ifcss.org]
          + all references to HBF v1.0 changed to v1.1 [cyl@ifcss.org]
          + added JISX0208-1990 and KSC5601-1987 as valid
            HBF_CODE_SCHEMEs [rap@doc.ic.ac.uk]
          + The bit about vendor versions of Unicode is wrong. v1.1 comes
            first; vendor extensions of it may come later.
            [rap@doc.ic.ac.uk]
            
   Draft 1.02 (1994/07/20)
          
          + "COPYRIGHT" of HBF file is now identified with "COMMENT"
            line. [rap@doc.ic.ac.uk]
          + "COPYRIGHT" & "NOTICE" definitions changed to conform to
            X11R6 BDF/XFLD properties. [rap@doc.ic.ac.uk]
          + appendix 2 proposed API implementation removed, to keep HBF
            Standard describing only file format.
          + all references to ETen 2.00.03 changed to 3.10
            [cyl@ifcss.org]
          + section 4 descriptions of full HBF merged into section 3
            STARTPROPERTIES explanation, and section 4 example of full
            HBF is now appendix 2. [rap@doc.ic.ac.uk]
            
   Draft 1.03 (1994/07/22)
          
          + reference to Ross Paterson's sample API implementation and
            availability added to section 1. [nsysu11@cc.nsysu.edu.tw]
          + Reference part at end of section 1 moved out of HBF Standard
            into Appendix 3 as Endnotes. [cai@neurophys.wisc.edu]
          + section 3 (2) HBF_CODE_SCHEME explanation updated.[rap]
          + discarded the "v" in front of version numbers when used in
            HBF_CODE_SCHEME, as it's not used in the similar XLFD
            property CHARSET_REGISTRY. [cyl@ifcss.org]
            
   Draft 1.04 (1994/07/23)
          
          + many references to "hanzi" changed to "character" in the text
            of this Standard to reflect support of any uniform bitmaps,
            and not just hanzi bitmaps. [rap@doc.ic.ac.uk]
            
   Draft 1.05 (1994/07/25)
          
          + all references to X11R6 BDF and X11R6 XLFD changed to BDF 2.1
            and XLFD 1.5, respectively, since BDF hasn't changed for two
            X11 revisions. [rap]
          + implementation note appended to bitmapFileName. [rap]
          + correction to STARTPROPERTIES p: BDF p isn't optional, but
            the whole properties section is optional.[rap]
          + specs for single and triple byte fonts added. [cai]
            
   Draft 1.06 (1994/07/27)
          
          + converted document to HTML. Some restructuring and stylistic
            changes.[rap]
          + added description of SIZE entry (required for BDF
            compatability).[rap]
          + moved case-insensitivity to FONT and HBF_CODE_SCHEME (since
            others may not be case-insensitive; bitmap filenames
            certainly aren't).[rap]
            
   Draft 1.07 (1994/09/01)
          
          + contributors acknowledged for HBF 1.1, in History section.
            [a7621gac@wiuni11.bitnet]
          + more html links in Code Scheme section. [cyl]
          + CHARS, which is now optional, is only required by BDF, but
            can be calculated with sample implementation such as
            hbftobdf. [rap]
          + added to Code Scheme section: GB, JIS and KSC code schemes
            may be either Graphic Left (GL) or Graphic Right (GR)
            encoded, but GL encoding should be used if consistency with
            X11R6 distribution is desired.[a7621gac]
          + updated Appendices and References sections. [a7621gac]
          + added CNS 11643-1992 to Code scheme section, since CNS HBF
            fonts are now readily accesible. [cyl]
            
   Draft 1.08 (1994/09/18)
          
          + HBF 1.1 will not adopt any author's API implementation as the
            standard, but a separate document will be provided to
            introduce HBF 1.1, and available sample implementations, with
            links to the HBF font files themselves, and related
            information.
          + adopted as HBF version 1.1
            
   Patch Level 1 (1994/09/21)
          
          + minor changes to Code Scheme names so that spaces and hyphens
            correlates to the periods as used in the BDF Property
            "CHARSET_REGISTRY"
ÿ