Subject: Re: hanzi bitmap font (HBF) Standard

From: Ross Paterson <[email-masked]>
Date: Fri, 28 May 1993 14:59:00 BST

On coding schemes,

> Accepted values for HBF_CODE_SCHEME in this Standard v1.0 are:
> [...]
>        Unicode vendor v1.1 -- not simply "Unicode"; use the specific
>                               version "v1.1" supplied by "vendor".
>                               Unicode is still evolving and thus
>                               different versions exist.

I think that Unicode is a good deal more well-defined than this -- the
UniHan area (4E00-9FA5) is essentially set in concrete now, as are the CJK
punctuation areas of concern to us, and most of the rest of the standard.
Unicode 1.0 is described by the published books, and a couple of tables
on unicode.org.  A few minor changes in areas separate from Chinese
computing are described in the Unicode 1.0.1 addendum also at that FTP
site.  A few extra presentation forms from ISO 10646 are added in Unicode
1.1, but again this has no impact on Chinese computing.  Now Unicode 1.1
is equivalent to ISO/IEC 10646-1 UCS2, Level 3 -- they cover exactly
the same collection of characters, with identical code assignments.
Future versions might add more hanzi, and may add a combining-form method
of extending the hanzi set, but they can be expected to leave existing
assignments alone (the credibility of both standards is at stake).

Different vendors might put different stuff in the Private Use Area
(E000-F8DD), but that's peripheral.  Besides, Unicode versions
are independent of vendors, though vendors might define their own
sub-versions.  Thus the coding schemes should be called

        Unicode 1.0
        Unicode 1.0.1
        Unicode 1.1

but these are all equivalent as far as the Chinese portion is concerned,
and the first two are now obsolete.  You could add an optional vendor
and vendor-version if you're using the Private Use Area, but that's
best avoided.

As for the C interface, I would have expected just

        typedef struct {
                /* fields corresponding to the definition */
                /* plus internal table of font files */
        } HBF_FILE;

        HBF_FILE *      HBF_OpenFont(const char *hbfFileName);
        int             HBF_CloseFont(HBF_FILE *hbfFile);
        int             HBF_GetBitmap(HBF_FILE *hbfFile,
                                        HBF_HzCode code,
                                        char *buffer);

(I can't see how you'd avoid re-opening font files all the time with the
existing definition.)
--
Ross Paterson <[email-masked]>
Department of Computing, Imperial College, London SW7