From mcpong@uxmail.ust.hk Sun Feb 28 02:38:09 1993 Return-Path: Date: Sun, 28 Feb 93 16:26:44 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF v1.0 draft 0.2 Status: RO Standard for the File Format of Hanzi Bitmap Font (HBF) Version 1.0 ------------------------------------------------------------------- Draft v0.1 -- released for comment on 1993/02/17. Draft v0.2 -- released for comment on 1993/02/28. changes from v0.1: -- 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. Table of Content 0. Acknowledgement 1. Introduction 2. Definition of terms 2.1 "bitmap file" 2.2 "HBF header file" (i.e. "HBF file") 3. Simple HBF file 4. Full HBF file Appendix 1: Formal Syntax of simple HBF file Appendix 2: Implementation A2.1 Basic Application Programmer Interface (API) routines A2.2 Desirable Application Programmer Interface (API) routines A2.3 Desirable utility programs for manipulating HBF files Appendix 3: Rationale for the HBF_CODE_RANGE property [[ Comment/rationale is enclosed in "[[" & "]]". It'll be deleted in the final draft. -- mcpong@uxmail.ust.hk ]] [[ I may forget to incorporate some of the suggested API, etc. Please mention any desirable missing ones in feedback. -- mcpong ]] 0. Acknowledgement This document is the 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. [[ Apology to those who have been missed from the list or misspelling of names, due to ignorance of the drafter of this document. (Update of the list is welcome.) -- mcpong ]] CAI@neurophys.wisc.edu (CAI, Yidao) jiang@ifcss.org (JIANG, Yuan) lee@umunhum.stanford.edu (LEE, Fung Fung) 87P0786@csdvax.csd.unsw.edu.au (NI, Hongbo) mcpong@uxmail.ust.hk (PONG, Man-Chi) simpson@math.psu.edu (SIMPSON, Stephen G.) 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 on the mailing list (soft.list), etc., are ftp'able from ifcss.org:/software/fonts/d/. Also thanks to xiaofei@ifcss.org (WANG XiaoFei) who maintains the mailing list "soft-authors@ifcss.org" for the discussion. 1. Introduction The aim of the standard is to allow different software to access a canonical representation of "hanzi bitmap font" (HBF). This is achieved by using a separate "HBF header file" (or "HBF file" for short) to specify the properties of the HBF and the index (or file offset) information to access the separately existing "bitmap files" of the HBF. The "bitmap files" exists independently of the "HBF file". The implementation of the standard will alleviate the problem that a certain software is usually distributed with its own hanzi bitmap file(s). This reduces the need to keep different formats of the same hanzi bitmap fonts, thus reducing the disk space requirement. It also provides an easy way to access existing commonly available bitmap files, such as those distributed with a commercial Chinese system in PC. The purpose of this document is to describe the features and the formal syntax (using Extended Backus-Naur Form) of the "hanzi bitmap font" (HBF) file format, based on the discussion in the mailing list "soft-authors@ifcss.org". The format of HBF essentially follows X11R5 X Logical Font Description (XLFD) Conventions version 1.4 [1] and X11R5 Bitmap Distribution Format (BDF) version 2.1 [2]. A "simple HBF file" contains the minimum number of properties relevant to a fixed-width hanzi bitmap font. A "full HBF file" can have all the properties of a X11R5 font file, so that it can be converted easily to an X11R5 BDF file, say, using a utility program "hbf2bdf". Software running in non-X window system can simply use the "simple HBF file" format, and ignore any complicated properties specified in the "full HBF file". A utility program "tofhbf" (not "shbf2fhbf", which has more than 8 letters and is not acceptable in MS-DOS) can convert a "simple HBF file" to a "full HBF file" so that default or user-specified X11R5 font properties can be added to the "full HBF file". The details of the X11R5 font properties used in the "full HBF file" format can be found in references [1] and [2]. They are only briefly described in this document. The rest of this document is organized as follows. In section 2, some special terms used in this documents are defined. In section 3, the "simple HBF file" is described. In section 4, the "full HBF file" is described. If the reader is not interested in X11R5 font properties, section 4 can be skipped. Appendix 1 gives the formal syntax of the "simple HBF file" format. This serves to check the compatibility of any implementation against this standard. For the sake of brevity as some readers may not be interested in X11R5 BDF file format, the syntax of "full HBF file" is not described, and the details can be found in references [1] and [2]. Appendix 2 gives the application programmer interface (API) routines and utility programs to support this standard. The references are: [1] X Logical Font Description Conventions version 1.4, MIT X Consortium Standard, X11R5 (1991), by Jim Flowers of Digital Equipment Corporation. (available in X11R5 distribution mit/{hardcopy,doc}/XLFD/.) [2] Bitmap Distribution Format version 2.1, MIT X Consortium Standard, X11R5 (1991), by Adobe Systems, Inc. (available in X11R5 distribution mit/{hardcopy,doc}/BDF/.) 2. Definition of terms Each hanzi is represented by a two-byte "hanzi code" in a computer system, no matter which "hanzi code scheme" is used. The most significant byte of a hanzi code is also called "byte 1" (or "first byte") and the least significant byte "byte 2" (or "second byte") of the hanzi code. Every "Hanzi Bitmap Font" (HBF) consists of a "HBF header file" and "bitmap file(s)". A "HBF header file" is an ASCII text file which describes: (1) the properties of the font, (2) for different ranges of valid hanzi code, the index (or file offset) information to the bitmap file(s). A "bitmap file" is a binary file of hanzi bitmaps indexed by the HBF header file. This "HBF Standard v1.0" only takes care of uncompressed bitmap file which stores the "full bitmaps" of each hanzi glyph. (Compressed bitmap files will be considered in future versions.) Without confusion, we can use the term "HBF file" to mean the "HBF header file" because it defines the essential information of a HBF. Common hanzi code schemes are: GB2312-80 Big5 Unicode v1.1 Note that different vendors' bitmap files for Big5 may have the vendors' added hanzi codes for some rarely used hanzi. It is more precise to say that a certain Big5 hanzi code scheme is "Big5 Vendor-or-System-Name version". Thus, we have "Big5 ETen v1.0" "Big5 ETen v2.0" which have different number of hanzi codes in the respective "bitmap files". 2.1 "bitmap file" A "bitmap file" is a file of binary data where the bitmaps of individual hanzi "glyphs" are linearized into the byte sequence in the file. (A glyph is a technical term in typography. It means a symbol that conveys information nonverbally. In this document, it refers to a hanzi symbol.) Each bitmap of a glyph shows the shape of the hanzi, with bits '0' represent the background and bits '1' represent the shape of the hanzi in the upright position, as usually seen as black printed hanzi on white background. A bitmap of size "Width x Height" bits is stored as a sequence of Height*((Width+7)/8) bytes, where integer division with truncation of decimal places is used in the calculation. The bits are stored row-wise, with each row stored in ((Width+7)/8) bytes. The most significant bit of the first byte is the upper-left bit of the glyph image. The values of the unfilled bits of the last byte for a row of bits are immaterial. The bytes of the bitmaps follows each other consecutively. E.g., a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes a 16x15 bitmap occupies 15*((16+7)/8) = 30 bytes a 15x16 bitmap occupies 16*((15+7)/8) = 32 bytes a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes (Note that the most significant bit of a byte is precisely defined, independent of whether the machine is a little or a big endian machine.) 2.2 "HBF header file" (i.e. "HBF file") A HBF (header) file is an ASCII text file following the X11R5 BDF format, but with modification to tailor for the characteristics of hanzi font, which is always a fixed pitch font (consisting of fixed width glyphs). It contains the font name and other properties of the font, follows by index (or file offset) information to the bitmap file(s). (For the rationale of the indexing scheme in HBF in this standard and the comparison with other schemes, please see Appendix 3, an extract of a mail from F.F.Lee.) In each of the following sections, a sample HBF file is given and then the properties of HBF are described. Each property of HBF is described in one line terminated with the end-of-line character, which is system specific. Each property is introduced by a keyword spelt as a string of upper case letters. Most of the keywords are the same as those of X11R5 BDF. New keywords introduced for HBF properties are prefixed with "HBF_". If a HBF keyword is made up from more than one English word, the words are separated by "_" for better readability. Note that "_" is used as word separator in some X11R5 BDF keywords but not in others, whereas "_" is used consistently in HBF keywords. The property value is usually either a string or an integer-string. The term "integer-string" is used in reference [1]. It actually means an "integer" in textual form. An unsigned integer can be given in either the decimal, hexadecimal, or octal format. An octal integer is introduced by the prefix '0'. A hexadecimal integer is introduced by the prefix "0x", as in the programming language C. For readability purpose, either a decimal or hexadecimal format is recommended, depending on which property is being specified. An unquoted string is not enclosed by a pair of double quotes '"'. A quoted string is enclosed by a pair of double quotes '"'. The letters in a string, either quoted or unquoted, are case insensitive, i.e. a lower case letter is equivalent to the corresponding upper case letter. The quote character '"' is not allowed in a string. [[ I can't find in the XLFD or BDF documents ([1] and [2]) saying whether \" is allowed to mean " or not. Thus to play safe to ensure compatibility with BDF, just ban the use of " in quotedString and unquotedString. -- mcpong ]] 3. Simple HBF file The following is an example simple HBF file which uses the bitmap file supplied in the ETen system Version 2.00.03. The keywords specific to HBF are preceded by "HBF_". Other keywords have the same meaning of the X11R5 BDF convention [2]. HBF_VERSION 1.0 HBF_CODE_SCHEME Big5 ETen v2.00.03 FONT ETenKai24 HBF_BITMAPBOUNDINGBOX 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 "fanti" DEFAULT_CHAR 0xA140 COPYRIGHT "public domain simple HBF file (1993)" NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." ENDPROPERTIES COMMENT Users should observe the copyright of the individual bitmap font files. CHARS 13867 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-0xA3BF "SPCFONT.24" 0 HBF_CODE_RANGE 0xA440-0xC67E "STDFONT.24K" 0 HBF_CODE_RANGE 0xC6A1-0xC8D3 "SPCFSUPP.24" 0 HBF_CODE_RANGE 0xC940-0xF9FE "STDFONT.24K" 388872 HBF_END_CODE_RANGES COMMENT COMMENT Non-hanzi symbol (408 chars) bitmaps in file "SPCFONT.24". COMMENT Vendor-specific symbols (365 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 simpson@math.psu.edu (Stephen G. Simpson) COMMENT -- these may vary depending on the version of the ETen system. ENDFONT The following explains the properties which are relevant to this simple HBF file. (0) COMMENT string string: an optional comment. The COMMENT line can appear anywhere in the HBF file. (1) HBF_VERSION formatVersion formatVersion: an unquoted string specifying which version of HBF format this file is conformed to, so that backward compatibility can be supported even if there is a change in the format definition. E.g. HBF_VERSION 1.0 This serves to distinguish HBF Standard v1.0 files from X11 BDF files. Note that the X11 keyword "STARTFONT" is not used. (2) HBF_CODE_SCHEME hanziCodeSchemeName bitmapSourceName bitmapSourceVersion hanziCodeSchemeName: an unquoted string representing the hanzi code scheme. bitmapSourceName, bitmapSourceVersion: optional unquoted strings (appear together) representing the name of the source of the bitmap files, and the version, respectively. Usually, the vendor or the system providing the bitmap files is the source of the bitmap files. This property HBF_CODE_SCHEME is similar to the X11R5 X Logical Font Description (XLFD) property CHARSET_REGISTRY. With this extra HBF_CODE_SCHEME property, one can easily see what hanzi code scheme the HBF file supports. Like CHARSET_REGISTRY, a clearing house is required to register the hanziCodeSchemeName. At least GB2312-80 and Big5 are accepted values in this Standard v1.0. [[ Where will be the clearing house is yet to be decided. -- mcpong ]] Accepted values for HBF_CODE_SCHEME are: GB2312-80 -- not simply "GB"; there are many GuoBiao's for hanzi. Big5 -- any so-called "Big5" bitmap file(s) can be used, but those bitmap file(s) must conform to the Big5 hanzi code standard without vendor-added hanzi code. The Big5 hanzi code standard 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 v2.00.03 -- not simply "Big5"; use specifically the bitmap files in the ETen system v2.00.03 which contains vendor-specific hanzi code. Unicode Vendor v1.1 -- not simply "Unicode"; the specific version "v1.1" supplied by "Vendor". Unicode is still evolving and thus different versions exist. An application can match the hanziCodeSchemeName value of a HBF file if it wants to find a font conforming to a certain code scheme. Further matches of bitmapSourceName and bitmapSourceVersion will give a more precise conformance. These two values are not so important in most cases, and thus they are optional values. (3) FONT fontName fontName: either a simple case insensitive string with alphanumeric characters ('a'-'z', 'A'-'Z', '0'-'9') or a font name conforming to the X11 XLFD standard [1]. The later case is illustrated when a full HBF file is described in next section. The font name should be suggestive. E.g., the following refers to the same font, a 24x24 bitmap Kai style font from the ETen system: etenkai24 ETenKai24 ETENKAI24 (4) HBF_BITMAPBOUNDINGBOX 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 the origin of the glyph bounding-box. Bounding-box values (w h xd yd) are the same for each glyph in a hanzi font which has fixed pitch. The values are in pixels of the output device. A bounding-box is shown below. |<--- width --->| - ----------------- - ^ | | | ^ | | | | | ascent | | | | | | | | height | | | | | baseline ---> - ----O------------ | point "O" = Origin | | | | | yd = descent | | | | | v | | | v - ----------------- - |<--| xd The bitmap bounding-box bounds the bitmap of a glyph; thus its width and height are equal to the width and height of the bitmap. However, 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 for some letters in an ASCII font, like 'g', 'j', 'Q', etc., they have "descents" extending below the baseline. The xd and yd values of a bounding-box specifies the offset of the origin from the lower left corner of the bounding-box. The HBF_BITMAPBOUNDINGBOX value is actually the X11R5 BDF property "BBX" for individual glyph in a font. For a hanzi font, since all glyphs have equal bounding-box, we only specify the glyph bounding-box once as the HBF_BITMAPBOUNDINGBOX property. Another related property FONTBOUNDINGBOX is described next. Some examples are then shown to show the interaction of FONTBOUNDINGBOX and HBF_BITMAPBOUNDINGBOX. (5) FONTBOUNDINGBOX wFont hFont xdFont ydFont 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 the origin of the font bounding-box. FONTBOUNDINGBOX is an X11R5 BDF property. The interpretation in HBF is the same as in X11R5 BDF. A glyph of a font, no matter it is variable width or fixed width, is usually shown within the extent of the font bounding-box for the glyph. A hanzi glyph bitmap (i.e. its bounding-box) may be placed anywhere inside the font bounding-box, Thus it is required that: w of font bounding-box >= w of bitmap bounding-box h of font bounding-box >= h of bitmap bounding-box The FONTBOUNDINGBOX allows for the specification of inter-glyph and inter-line-of-text spacing. For hanzi font, usually, the sizes of HBF_BITMAPBOUNDINGBOX and FONTBOUNDINGBOX are the same. In such case, the yd value of FONTBOUNDINGBOX (and HBF_BITMAPBOUNDINGBOX) may still be non-zero due to the need to align nicely with an ASCII font along a line of text. E.g., use FONTBOUNDINGBOX 24 24 0 -2 instead of FONTBOUNDINGBOX 24 24 0 0 to align nicely with an ASCII font with "FONTBOUNDINGBOX 12 24 0 -2" which contains letters with descent "-2", such as 'g', 'j', 'Q', etc. The following shows an example of unequal bitmap and font bounding-boxes: --- is the boundary of the FONTBOUNDINGBOX 16 18 0 -2. ... is the top and bottom boundaries of the HBF_BITMAPBOUNDINGBOX of a font consisting of 16x15 bitmap: HBF_BITMAPBOUNDINGBOX 16 15 0 -1. |<--- 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 value of HBF_BITMAPBOUNDINGBOX. a blank row--> | | v -2----------------- - -2 = yd value of FONTBOUNDINGBOX. The following are some more examples to illustrate the relationships between FONTBOUNDINGBOX and HBF_BITMAPBOUNDINGBOX. Suppose we have five HBF files: HBF1, HBF2, HBF3, HBF4, HBF5. 16x16 bitmap HBFs: ------------------ HBF1: HBF_BITMAPBOUNDINGBOX 16 16 0 -2 FONTBOUNDINGBOX 16 16 0 -2 HBF2: (to allow for inter-line-of-text spacing of 2 pixels with the glyph bitmap aligned at the bottom of the FONTBOUNDINGBOX) HBF_BITMAPBOUNDINGBOX 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_BITMAPBOUNDINGBOX 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_BITMAPBOUNDINGBOX 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_BITMAPBOUNDINGBOX 16 15 0 -1 FONTBOUNDINGBOX 16 18 0 -2 Note that in most case, FONTBOUNDINGBOX and HBF_BITMAPBOUNDINGBOX are the same; and the application need not concern with FONTBOUNDINGBOX if the application does not work with mixed fonts. (6) STARTPROPERTIES p p: an unsigned integer. It indicates the number of font properties that follow this line. (7) FAMILY_NAME fontFamilyName fontFamilyName: a quoted string that 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 hanzi font style: FAMILY_NAME "kai" (8) ADD_STYLE_NAME styleInfoString styleInfoString: a quoted string that 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. E.g., ETenKai24 is a font of "fanti" hanzi (meaning "traditional hanzi") and we would like to document this fact: ADD_STYLE_NAME "fanti" (9) DEFAULT_CHAR defaultCharCode defaultCharCode: an unsigned integer specifying the hanzi code to be used when an attempt is made to display an undefined or non-existent glyph in the font. E.g., 0xa140 is the blank character in the ETen system fonts: DEFAULT_CHAR 0xa140 A HBF file must specify this property to facilitate processing. (Note: in X11R5 BDF, this property is optional.) [[ F.F.Lee recommends making DEFAULT_CHAR compulsory. -- mcpong ]] (10) COPYRIGHT string string: a human-understandable quoted string that gives the copyright information of the legal owner of the HBF file. E.g., COPYRIGHT "public domain simple HBF file (1993)" (11) NOTICE string string: a human-understandable quoted string that gives the copyright information of the legal owner of the font design of the bitmap file. E.g., NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." (12) ENDPROPERTIES This line indicates the end of the STARTPROPERTIES section. (13) CHARS totalNumberOfGlyphsInFont totalNumberOfGlyphsInFont: an unsigned integer specifying the total number of the glyphs in this HBF. E.g., CHARS 13867 There are 13867 glyphs in the bitmap files of the ETen system v2.00.03 as illustrated in the HBF_START_CODE_RANGES section below. (14) HBF_START_BYTE_2_RANGES r r: an unsigned integer showing how many valid sub-ranges are represented by the byte 2 of the hanzi codes. [[ I used HBF_START_BYTE_2_RANGES instead of HBF_START_LOW_BYTE_RANGES to allow for future extension of 4-byte code in the ISO10646 encoding standard. Then HBF_START_BYTE_4_RANGES could be used. -- mcpong ]] E.g., there are two valid sub-ranges in the ETen Big5 code: START_BYTE_2_RANGES 2 (15) 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 hanzi codes. It is required that: 0 <= rangeStart <= rangeEnd <= 0xFF The sub-ranges must be given in increasing order. (This saves the need to sort the sub-ranges in implementation.) [[ F.F.Lee recommends the last point. For an implementation independent specification, ideally one should not specify any details of implementation. But this is a good idea, and so we can enforce it by stating this explicitly in the Standard. -- mcpong ]] E.g., there are two valid sub-ranges of byte 2 for ETen Big5 code: HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE (16) HBF_END_BYTE_2_RANGES This line indicates the end of the HBF_START_BYTE_2_RANGES section. (17) HBF_START_CODE_RANGES r r: an unsigned integer showing how many code-ranges of hanzi code are valid in the whole coding space of the HBF. E.g., there are four valid code-ranges in the ETen Big5 coding space: HBF_START_CODE_RANGES 4 (18) HBF_CODE_RANGE firstCode-lastCode bitmapFileName offset firstCode, lastCode: unsigned integers showing the first and the last hanzi code of a valid code-range of the coding space of the HBF. For 2-byte hanzi code, it is required that: 0 <= firstCode <= lastCode <= 0xFFFF No two HBF_CODE_RANGE lines should have overlapping code-ranges. The code-ranges must be given in increasing order of firstCode. (This saves the need to sort the sub-ranges in implementation.) bitmapFileName: a quoted string of the name of the bitmap file containing the bitmaps for the glyphs in the code-range. offset: an unsigned integer showing the file offset of the bitmap of the hanzi code firstCode in the bitmap file. Other bitmaps of the hanzi code in the same CODE_RANGE follows in the bitmap file. E.g., there are four valid code-ranges for the font ETenKai24 using ETen v2.00.03 bitmap files. The bitmaps are stored in three different files, with the frequently-used and less-frequently-used hanzi bitmaps stored in the same file "STDFONT.24K": HBF_CODE_RANGE 0xA140-0xA3BF "SPCFONT.24" 0 HBF_CODE_RANGE 0xA440-0xC67E "STDFONT.24K" 0 HBF_CODE_RANGE 0xC6A1-0xC8D3 "SPCFSUPP.24" 0 HBF_CODE_RANGE 0xC940-0xF9FE "STDFONT.24K" 388872 (19) HBF_END_CODE_RANGES This line indicates the end of the HBF_START_CODE_RANGES section. (20) ENDFONT This line marks the end of the HBF file. 4. Full HBF file The following is an example full HBF file which is equivalent to the simple HBF file described in section 3. This full HBF file can be converted from the simple HBF file using the utility program "tofhbf" which adds the additional font properties with default values, possibly calculated from the property values in the simple HBF file. HBF_VERSION 1.0 HBF_CODE_SCHEME Big5 ETen v2.00.03 FONT ETenKai24 COMMENT COMMENT An equivalent full X11R5 XLFD conforming font name is COMMENT -eten-kai-medium-r-normal-fanti-24-240-80-80-c-240-big5.eten.v2.00.03-0 COMMENT which is formed from the first 14 properties listed in COMMENT the STARTPROPERTIES section below. COMMENT Any of these properties is optional, as in the simple HBF file. COMMENT SIZE 24 75 75 HBF_BITMAPBOUNDINGBOX 24 24 0 -2 FONTBOUNDINGBOX 24 24 0 -2 COMMENT COMMENT Begin Logical Font Description -- 20 special properties for this FONT COMMENT STARTPROPERTIES 20 FOUNDRY "eten" FAMILY_NAME "kai" WEIGHT_NAME "medium" SLANT "r" SETWIDTH_NAME "normal" ADD_STYLE_NAME "fanti" PIXEL_SIZE 24 POINT_SIZE 240 RESOLUTION_X 80 RESOLUTION_Y 80 SPACING "c" AVERAGE_WIDTH 240 COMMENT '-' can't be used in full XLFD name, thus use '.' in CHARSET_REGISTRY CHARSET_REGISTRY "big5.eten.v2.00.03" CHARSET_ENCODING "0" FONTNAME_REGISTRY "" FONT_DESCENT 2 FONT_ASCENT 22 COMMENT COMMENT All the above properties are discussed in X11R5 XLFD Conventions. COMMENT COMMENT The rest is the same as the simple HBF file in section 3. COMMENT DEFAULT_CHAR 0xA140 COPYRIGHT "public domain simple HBF file (1993)" NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." ENDPROPERTIES COMMENT Users should observe the copyright of the individual bitmap font files. CHARS 13867 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-0xA3BF "SPCFONT.24" 0 HBF_CODE_RANGE 0xA440-0xC67E "STDFONT.24K" 0 HBF_CODE_RANGE 0xC6A1-0xC8D3 "SPCFSUPP.24" 0 HBF_CODE_RANGE 0xC940-0xF9FE "STDFONT.24K" 388872 HBF_END_CODE_RANGES COMMENT COMMENT Non-hanzi symbol (408 chars) bitmaps in file "SPCFONT.24". COMMENT Vendor-specific symbols (365 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 simpson@math.psu.edu (Stephen G. Simpson) COMMENT -- these may vary depending on the version of the ETen system. ENDFONT Apart from the properties given for the simple HBF file, the extra optional X11 relevant properties are described in the documents in the X11R5 distribution in mit/hardcopy/XLFD/ [2] and mit/hardcopy/BDF/ [1]. They are briefly described here. (1) SIZE pointSize xResolution yResolution pointSize: an unsigned integer representing the point size of the character. In typography, 1 inch = 72.27 points. Here let it be the no. of pixels on screen and use an integer value. xResolution, yResolution: The resolution of the device for which the bitmap is intended. E.g. on a 75 dpi (dots per inch) screen, we have SIZE 24 75 75 (2) FOUNDRY foundryName foundryName: a string representing which organization digitized and supplied the font data, or if different, the identifier of the organization that last modified the font shape or metric information. (3) FAMILY_NAME fontFamilyName fontFamilyName: a quoted string that identifies the "family" of typeface designs that are all variations of one basic typographic style. (4) WEIGHT_NAME weightName weightName: either one of the strings "medium" | "bold" | "demibold" | ... etc. weightName is a quoted string that identifies the font's typographic weight, that is, the nominal blackness of the font, according to the FOUNDRY's judgment. This may be used to get the bold variant of a font. (5) SLANT slantString slantString: either one of the strings "r" | "i" | "o" | "ri" | "ro" | "ot" "r": regular. "i": italic. "o": oblique. "ri": reverse italic. "ro": reverse oblique. "ot": other. slantString is a quoted code-string that indicates the overall posture of the typeface design used in the font. (6) SETWIDTH_NAME widthName widthName: either one of the strings "normal" | "condensed" | "narrow" | "double wide" widthName is a quoted string that gives the font's typographic proportionate width, that is, the nominal width per horizontal unit of the font, according to the FOUNDRY's judgment. In scaling up or down the size of a glyph based on a bitmap of a certain size, one may make use of this property to get a better estimate of the hanzi stroke width of the whole set of glyphs. (7) ADD_STYLE_NAME styleInfoString styleInfoString: a quoted string that 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. (8) PIXEL_SIZE devicePixelSize devicePixelSize: an unsigned integer-string typographic metric in device pixels that gives the body size of the font at a particular POINT_SIZE and RESOLUTION_Y. (9) POINT_SIZE pointSizeOfFont pointSizeOfFont: is an unsigned integer-string typographic metric in device-independent units that gives the body size for which the font was designed. This field usually incorporates additional vertical spacing that is considered part of the font design. pointSizeOfFont is expressed in decipoints (tenths of points). Points are as defined in the X protocol or 72.27 points equal 1 inch. (10) RESOLUTION_X xResolutionNumber (11) RESOLUTION_Y yResolutionNumber xResolutionNumber, yResolutionNumber: unsigned integer-strings that give the horizontal and vertical resolution, measured in pixels or dots per inch (dpi), for which the font was designed. The separation of pixel or point size and resolution is necessary because X allows for servers with very different video characteristics. (12) SPACING spacingString spacingString: either one of the string "p" | "m" | "c" "p": proportional. "m": monospaced. "c": charcell. spacingString is a quoted code-string that indicates the escapement class of the font, that is, monospace (fixed pitch), proportional (variable pitch), or charcell (a special monospaced font that conforms to the traditional data processing character cell font model). (13) AVERAGE_WIDTH glyphWidthInDecipixel glyphWidthInDecipixel: an unsigned integer-string typographic metric value that gives the unweighted arithmetic mean width of all glyphs in the font (measured in tenths of pixels). For monospaced and character cell fonts, this is the width of all glyphs in the font. (14) CHARSET_REGISTRY quotedString (15) CHARSET_ENCODING quotedString Together identify the character set used to encode the glyphs of the font (and implicitly the font's glyph repertoire), as maintained by the X Consortium character set registry. CHARSET_REGISTRY is a quoted string of x-registered-name that identifies the registration authority that owns the specified encoding. CHARSET_ENCODING is a quoted string of registered-name that identifies the coded character set as defined by that registration authority. Usually, CHARSET_ENCODING is either CHARSET_ENCODING "0" or CHARSET_ENCODING "1" E.g. CHARSET_REGISTRY "big5.eten.v2.00.03" so that it is consistent with the HBF_CODE_SCHEME property. (16) FONT_DESCENT descentUnitNumber (17) FONT_ASCENT ascentUnitNumber descentUnitNumber is an integer that gives the recommended typographic descent below the baseline for determining interline spacing. ascentUnitNumber is an integer that gives the recommended typographic ascent above the baseline for determining interline spacing. Appendix 1: Formal Syntax of simple HBF file. The following uses the formal notation Extended Backus-Naur Form (EBNF) to describe a simple HBF file. A production rule has the following format: Non-terminal symbol ::= a combination of non-terminal symbols, terminal tokens, and meta-symbols. The left-hand-side can generate "items" on the right-hand side of each "production rule". The following is a list of meta-symbols: "." terminates a rule. "( items )" means a sequence of items. "{ item }" means item will be repeat for 0 or more times. "[ item ]" means item will be repeat for 0 or one times. "item1 | item2" means either item1 or item2 is valid. 'literal' is the literal string that should appear as it is (without the single-quote) in the rule. The terminal tokens (i.e. 'literal', keyword, identifier, numbers or strings) can be separated by one or more blank or tab characters. The property keywords are spelt in upper case letters. Other terminal tokens (literal strings and identifiers) are case insensitive; i.e. lower case letter is equivalent to upper case letter. This ensures backward compatibility in MS-DOS environment. Comment lines can appear anywhere, which have the form 'COMMENT' string EOLN EOLN is a system-specific line terminator character(s) . unquotedString ::= char { char } . quotedString ::= '"' char { char } '"' . /* char can be any printable ASCII character except '"'. */ [[ I can't find in the XLFD or BDF documents ([1] and [2]) saying whether \" is allowed to mean " or not. Thus to play safe to ensure compatibility with BDF, just ban the use of " in quotedString and unquotedString. -- mcpong ]] unsignedInteger ::= digit { digit } . /* unsigned integer in C language */ /* unsignedInteger can be read in by C scanf functions using %i format */ [[ By not enforcing 16-bit integer, the implementation should use variables of type "unsigned integer", not necessarily "short", to store the value. -- mcpong ]] unsignedInteger32 ::= digit { digit } . /* 32-bit unsigned integer */ /* unsignedInteger32 can be read in by C scanf functions using %l format */ /* digit is the ASCII characters '0' to '9' */ HBFHeaderFile ::= 'HBF_VERSION' formatVersion EOLN 'HBF_CODE_SCHEME' hanziCodeSchemeName [ bitmapSourceName bitmapSourceVersion ] EOLN 'FONT' fontName EOLN 'HBF_BITMAPBOUNDINGBOX' w h xd yd EOLN 'FONTBOUNDINGBOX' wFont hFont xdFont ydFont EOLN X11R5FontPropertySection 'CHARS' totalNumberOfGlyphsInFont EOLN HBFByte2RangeSection HBFCodeRangeSection 'ENDFONT' EOLN . formatVersion ::= unquotedString . hanziCodeSchemeName ::= unquotedString . bitmapSourceName ::= unquotedString . bitmapSourceVersion ::= unquotedString . fontName ::= unquotedString . w ::= unsignedInteger . /* usually in decimal format */ h ::= unsignedInteger . /* usually in decimal format */ xd ::= unsignedInteger . /* usually in decimal format */ yd ::= unsignedInteger . /* usually in decimal format */ wFont ::= unsignedInteger . /* usually in decimal format */ hFont ::= unsignedInteger . /* usually in decimal format */ xdFont ::= unsignedInteger . /* usually in decimal format */ ydFont ::= unsignedInteger . /* usually in decimal format */ totalNumberOfGlyphsInFont ::= unsignedInteger . /* usually in decimal format */ X11R5FontPropertySection ::= 'STARTPROPERTIES' numberOfX11R5FontProperties EOLN X11R5FontProperty { X11R5FontProperty } 'ENDPROPERTIES' EOLN . numberOfX11R5FontProperties ::= unsignedInteger . /* usually in decimal format */ X11R5FontProperty ::= 'FAMILY_NAME' fontFamilyName EOLN | 'ADD_STYLE_NAME' styleInfoString EOLN | 'DEFAULT_CHAR' defaultCharCode EOLN | 'COPYRIGHT' quotedString EOLN | 'NOTICE' quotedString EOLN . /* Only the X11R5FontProperty for simple HBF file is shown here. */ /* An X11R5FontProperty should appear once only. */ fontFamilyName ::= quotedString . styleInfoString ::= quotedString . defaultCharCode ::= unsignedInteger . /* usually in hexadecimal format */ HBFByte2RangeSection ::= 'HBF_START_BYTE_2_RANGES' numberOfByte2Ranges EOLN HBFByte2Range { HBFByte2Range } 'HBF_END_BYTE_2_RANGES' EOLN . numberOfByte2Ranges ::= unsignedInteger . /* usually in decimal format */ HBFByte2Range ::= 'HBF_BYTE_2_RANGE' rangeStart '-' rangeEnd EOLN . rangeStart ::= unsignedInteger . /* usually in hexadecimal format */ rangeEnd ::= unsignedInteger . /* usually in hexadecimal format */ HBFCodeRangeSection ::= 'HBF_START_CODE_RANGES' numberOfCodeRanges EOLN HBFCodeRange { HBFCodeRange } 'HBF_END_CODE_RANGES' EOLN . numberOfCodeRanges ::= unsignedInteger . /* usually in decimal format */ HBFCodeRange ::= 'HBF_CODE_RANGE' firstCode '-' lastCode bitmapFileName offset EOLN . firstCode ::= unsignedInteger . /* usually in hexadecimal format */ lastCode ::= unsignedInteger . /* usually in hexadecimal format */ bitmapFileName ::= quotedString . offset ::= unsignedInteger32 . /* usually in decimal format */ /* offset to (large) bitmap file, thus need 32-bit unsigned integer value */ Appendix 2: Implementation A2.1 Basic Application Programmer Interface (API) routines The implementation can define the following (abstract) data types: HBF_Handle /* a handle to access a HBF */ HBF_Struct /* a structure of information parsed from HBF file */ HBF_Octet /* an 8-bit byte */ PtrHBF_Octet /* pointer to HBF_Octet sequence (a bitmap) */ [[ "PtrHBF_Octet" is more readable than "HBF_Octet *" ]] HBF_HzCode /* a 16-bit hanzi code */ A sample implementation in Unix/C can be: typedef HBF_Struct * HBF_Handle ; typedef unsigned char HBF_Octet ; typedef HBF_Octet * PtrHBF_Octet ; typedef struct { unsigned char byte1 ; unsigned char byte2 ; } HBF_HzCode ; The following is a list of library routines for accessing a HBF file. HBF_Handle HBF_OpenFont( IN char * filename ); /* Open and initialize a HBF file. * * RETURN handle for the HBF; * NULL if error. */ /************************************************************/ int HBF_CloseFont( IN HBF_Handle handle ); /* Close a HBF file. * * RETURN 0 if OK; * 1 if error. * (may return > 1 to indicate other conditions; * yet to be defined.) */ /************************************************************/ char* HBF_GetProperty( IN HBF_Handle handle, IN char * propertyName ); /* Get the property of the given propertyName. * * RETURN the character string as if appeared after the keyword * of the property in the property line in the HBF file, * starting with a non-space character, with only one blank * character separating each pair of tokens in the string, * and with no trailing blanks; * or NULL if invalid HBF handle or invalid propertyName. * * The calling routine should free the returned string after use. * * In Standard v1.0, only properties in simple HBF file are valid. */ /************************************************************/ /* FONTBOUNDINGBOX information is expected to be frequently used, * thus a separate API routine to get this property. */ int HBF_GetFontBoundingBox( IN HBF_Handle handle, OUT unsigned int *width, OUT unsigned int *height, OUT unsigned int *xDisplacement, OUT unsigned int *yDisplacement ); /* Get the font bounding-box information for a given HBF. * * RETURN 0 if OK, and the font bounding-box information * is returned in OUT parameters. * 1 if invalid HBF handle. */ /************************************************************/ /* HBF_BITMAPBOUNDINGBOX information is expected to be frequently used, * thus a separate API routine to get this property. */ int HBF_GetBitmapBoundingBox( IN HBF_Handle handle, OUT unsigned int *width, OUT unsigned int *height, OUT unsigned int *xDisplacement, OUT unsigned int *yDisplacement ); /* Get the glyph bitmap bounding-box information for a given HBF. * * RETURN 0 if OK, and the glyph bitmap bounding-box information * is returned in OUT parameters. * 1 if invalid HBF handle. */ /************************************************************/ PtrHBF_Octet HBF_GetBitmap( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap for the given hanzi code. * * RETURN the pointer to the bitmap of the hanzi; * or the pointer to the bitmap of the DEFAULT_CHAR * if invalid hanzi code; * or NULL if invalid HBF handle. */ /* N.B.: * It is up to the application to show the bitmap properly within * the FONTBOUNDINGBOX, if different from HBF_BITMAPBOUNDINGBOX. */ /************************************************************/ A2.2 Desirable Application Programmer Interface (API) routines The API routines listed below are not required for an implementation to be conformed to the HBF Standard v1.0. It is foresee that they should be useful for some applications on some systems. To avoid the proliferation of different routine names for such functions, they are listed here, so that hopefully in future HBF Standard v2.0, they will be supported using such routine names. /************************************************************/ PtrHBF_Octet HBF_GetBitmapRotated90( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap rotated for 90 degrees anticlockwise * about the centre of the bitmap for the given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * or the pointer to the bitmap of the DEFAULT_CHAR * if invalid hanzi code; * or NULL if invalid HBF handle. * * This routine may be implemented in assembly code for speed. */ /************************************************************/ PtrHBF_Octet HBF_GetBitmapRotated180( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap rotated for 180 degrees anticlockwise * about the centre of the bitmap for the given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * or the pointer to the bitmap of the DEFAULT_CHAR * if invalid hanzi code; * or NULL if invalid HBF handle. * * This routine may be implemented in assembly code for speed. */ /************************************************************/ PtrHBF_Octet HBF_GetBitmapRotated270( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap rotated for 270 degrees anticlockwise * about the centre of the bitmap for the given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * or the pointer to the bitmap of the DEFAULT_CHAR * if invalid hanzi code; * or NULL if invalid HBF handle. * * This routine may be implemented in assembly code for speed. */ /************************************************************/ A2.3 Desirable utility programs for manipulating HBF files hbf2bdf < file.hbf > file.bdf Converts a HBF header file and the associated bitmap files to an X11R5 BDF file. tofhbf [ -f fileOfLinesOfExtraProperties ] simple.hbf > full.hbf Converts the simple HBF file to a full HBF file. The parameter fileOfLinesOfExtraProperties specifies a file which contains the extra HBF properties for a full HBF file. Appendix 3: Rationale for the HBF_CODE_RANGE property [[ Appendix 3 is added for completeness sake. If you have read F.F.Lee's discussion on why HBF_CODE_RANGE section is useful, you can ignore this part. At that time, "HBF_START_CODE_RANGES" was called "BeginIndex". -- mcpong ]] From: lee (Fung Fung Lee) Subject: HBF (Hanzi Bitmap Format) There are two parts in this article. Part I. Three Index Range Encoding Schemes ------------------------------------------ As we may have observed, almost any index design will work well with GB due to its simplicity. However, there are problems with BIG5 with the current index encoding. regions of BIG5 codes BIG5 coding --------------------- ----------------- 1. symbols (408) 0xa140 -- 0xa3bf 2. Undefined 0xa3c0 -- 0xa3fe 3. Frequent (5401) 0xa440 -- 0xc67e 4. Undefined 0xc6a1 -- 0xc8fe 5. Non-frequent (7652) 0xc940 -- 0xf9d5 6. Undefined 0xf9d6 -- 0xf9fe Suppose the BIG5-ordered raw bitmap file "foo16" contains only the bitmaps of hanzi in regions 1, 3, and 5. The blocks of bytes representing the bitmap of the Han characters is packed tightly so that the ordering relation is the same as that of the internal code. This is not only a "natural" ordering for most people, but also common in actual practice, such as ETEN's format. For many practical reasons, HBF must provide flexible and efficient indexing mechanisms so that it works with as many current formats as possible. Users can then use their own bitmap files (without change), even if they are not in the public domain!! For this type of format, the current proposal (A) will need about 200 indices: (for the moment, the "at" stuff is not included) BeginIndex A1-A1 40-7E A1-A1 A1-FE A2-A2 40-7E A2-A2 A1-7E A3-A3 40-FE A3-A3 A1-BF A4-A4 40-7E . . . F9-F9 A1-D5 EndIndex Let's consider another proposal (B) for the same example: BeginIndex A1-A2 40-7E A1-FE A3-A3 40-7E A1-BF A4-C5 40-7E A1-FE C6-C6 40-7E C9-F8 40-7E A1-FE F9-F9 40-7E A1-D5 EndIndex To further simplify, we have yet another proposal (C) for the same example: BeginIndex A140-A3BF 40-7E A1-FE A440-C67E 40-7E A1-FE C940-F9D5 40-7E A1-FE EndIndex Note how simple and similar this format is to the way the region table is originally described! Let's take a look at other examples using proposal C For cclib16: BeginIndex A1A1-A7FE A1-FE B0A1-F7FE A1-FE EndIndex For Unicode: BeginIndex 4E00-FA2D 00-FF EndIndex Well, which of the 3 proposals (A, B, C) do you guys prefer? Why? Part II What should "at" point to ---------------------------------- Given any of the 3 proposals above, there is sufficient information to compute the (relative) character order or position, but there is not necessarily sufficient information to compute the "byte offset". For example, in "chinese.16", there is copyright information and other stuff before the raw bitmaps; in Macintosh's Chinese bitmap files, there are even their proprietary index information! There are many technical and non-technical reasons that we do not want to change those bitmap files, but can still use them. Hence, we need pointers to the actual locations to the bitmaps! Suppose in the BIG5-ordered raw bitmap file foo16, the bitmaps of the codes A140, A440, C940 start at byte offsets 256, 24000, 186000 (I just made up the numbers), then we have for proposal C: BeginIndex A140-A3BF 40-7E A1-FE at 256 A440-C67E 40-7E A1-FE at 24000 C940-F9D5 40-7E A1-FE at 186000 EndIndex ######### End of Standard v1.0 for HBF ########## From simpson@math.psu.edu Sun Feb 28 08:23:33 1993 Return-Path: From: Stephen G Simpson Date: Sun, 28 Feb 93 09:18:27 -0500 To: soft-authors@ifcss.org Subject: response to recent postings by F. F. Lee Status: O F. F. Lee wrote: > Subject: BITMAPBOUNDINGBOX (renamed HBFBBX ?) vs. FONTBOUNDINGBOX > ... > I think Stephen understood well my most recent proposal, except for > some misunderstanding about the intention of FONTBOUNDINGBOX. > I'll clarify in the following comments. Slowly the light is dawning in my mind. I agree completely with F. F. Lee's comments. > Subject: BITMAPBOUNDINGBOX & API > ... > Fortunately, almost every major Chinese bitmap font file uses the > [top-bottom]x[left-right]x[1 is black] (HBF draft 0.1) including > CCLIB, ETen, Macintosh Chinese OS, BDF (please correct me if I am wrong). > So far, only Yawei raised a different case for ziku used by BYX. > I have not looked at ziku, but presumably it is just CCLIB rearranged. > In today's computer environment how important it is to keep two copies > of the same bitmap font files with only a difference in the ordering? My original posting on the BYX ZIKU fonts offered what I consider a strong reason in today's computer environment for storing ZIKU24 in sideways ordering. The reason is that BYX 1.1 uses ZIKU24 in sideways ordering, and we can't modify BYX because the source code for BYX is not available (nor is it likely to become available in the future). However, I accept the argument that the HBF 1.0 API should support only the upright ordering -- anything more is too cumbersome. I guess I will just have to continue storing both ZIKU24 and CCLIB.24 on my PC, even though they differ only in sideways/upright ordering for the most part. I am not too happy about this, but I don't want to rock the boat. -- S. Simpson From Ricky.Yeung@Eng.Sun.COM Fri Mar 5 02:39:12 1993 Return-Path: Date: Fri, 5 Mar 93 00:24:45 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: soft-authors@ifcss.org Cc: Ricky.Yeung@Sun.COM In-Reply-To: Dr. PONG Man Chi's message of Sun, 28 Feb 93 16:26:44 HKT <9302280826.AA04542@uxmail.ust.hk> Subject: Re: HBF v1.0 draft 0.2 Content-Length: 9824 Status: O [ Portions of original message deleted to save space. ] > The format of HBF essentially follows X11R5 X Logical Font > Description (XLFD) Conventions version 1.4 [1] and X11R5 > Bitmap Distribution Format (BDF) version 2.1 [2]. > > A "simple HBF file" contains the minimum number of properties > relevant to a fixed-width hanzi bitmap font. > > A "full HBF file" can have all the properties of a X11R5 font > file, so that it can be converted easily to an X11R5 BDF file, > say, using a utility program "hbf2bdf". > > Software running in non-X window system can simply use the > "simple HBF file" format, and ignore any complicated properties > specified in the "full HBF file". I wonder if it's necessary to explicitly distinguish two forms of HBF files. I think it's suffice to only point out the required properties and that all the other BDF properties are optional (then you can significantly reduce the size of this HBF spec). Note that software running in non-X window system don't care if the HBF file is simple or full format, they only see the API and retrieve the properties needed. > A utility program "tofhbf" (not "shbf2fhbf", which has more > than 8 letters and is not acceptable in MS-DOS) can convert Since HBF is a system independent spec, I think it's better not to mention system dependent obscurities. > (1) HBF_VERSION formatVersion How about calling it HBF_STARTFONT to be a true follower of BDF's STARTFONT? > A2.1 Basic Application Programmer Interface (API) routines > > The implementation can define the following (abstract) data types: > > HBF_Handle /* a handle to access a HBF */ Since it's an abstract data type, maybe the name like HBF_FONT would be more appropriate. > HBF_Struct /* a structure of information parsed from HBF file */ I don't think there is any user-accessible fields in this struct, and because HBF_FONT is an abstract data type, this shouldn't be exposed to the API. > HBF_Octet /* an 8-bit byte */ > PtrHBF_Octet /* pointer to HBF_Octet sequence (a bitmap) */ > > [[ "PtrHBF_Octet" is more readable than "HBF_Octet *" ]] Personally I found the name Octet quite awkward. Why not call it byte? Or better yet, BITMAP, which is defined clearly in this HBF spec. typedef char *BITMAP; > HBF_HzCode /* a 16-bit hanzi code */ If hanzi code is an abstract type, then you better define API routines to access/retrieve the 1st and 2nd bytes, etc. A struct or unsigned integer impementation has quite different implications to the application programmers. I propose to define HBF_HzCode to be a minimum 16-bit unsigned integer. > A sample implementation in Unix/C can be: > > typedef HBF_Struct * HBF_Handle ; > > typedef unsigned char HBF_Octet ; > typedef HBF_Octet * PtrHBF_Octet ; > > typedef struct { > unsigned char byte1 ; > unsigned char byte2 ; > } HBF_HzCode ; > > The following is a list of library routines for accessing a HBF file. > > HBF_Handle HBF_OpenFont( > IN char * filename ); > > /* Open and initialize a HBF file. > * > * RETURN handle for the HBF; > * NULL if error. > */ > /************************************************************/ > > int HBF_CloseFont( > IN HBF_Handle handle ); > > /* Close a HBF file. > * > * RETURN 0 if OK; > * 1 if error. > * (may return > 1 to indicate other conditions; > * yet to be defined.) > */ > /************************************************************/ > char* HBF_GetProperty( > IN HBF_Handle handle, > IN char * propertyName ); > > /* Get the property of the given propertyName. > * > * RETURN the character string as if appeared after the keyword > * of the property in the property line in the HBF file, > * starting with a non-space character, with only one blank > * character separating each pair of tokens in the string, > * and with no trailing blanks; > * or NULL if invalid HBF handle or invalid propertyName. > * > * The calling routine should free the returned string after use. I think you meant "should NOT free" here, otherwise the HBF library has to make a copy of the property value string on each inquiry. The returned property value should be treated as constant anyway. > * In Standard v1.0, only properties in simple HBF file are valid. Why put that restriction? > > int HBF_GetFontBoundingBox( > IN HBF_Handle handle, > OUT unsigned int *width, > OUT unsigned int *height, > OUT unsigned int *xDisplacement, > OUT unsigned int *yDisplacement ); > > /* Get the font bounding-box information for a given HBF. > * > * RETURN 0 if OK, and the font bounding-box information > * is returned in OUT parameters. > * 1 if invalid HBF handle. > */ > /************************************************************/ It seems better to have the function return 0 for error and non-zero otherwise, so that the programmer can simply use the ! operator to test for error (like many UNIX/C library routines). > /* HBF_BITMAPBOUNDINGBOX information is expected to be frequently used, > * thus a separate API routine to get this property. > */ > int HBF_GetBitmapBoundingBox( > IN HBF_Handle handle, > OUT unsigned int *width, > OUT unsigned int *height, > OUT unsigned int *xDisplacement, > OUT unsigned int *yDisplacement ); > > /* Get the glyph bitmap bounding-box information for a given HBF. > * > * RETURN 0 if OK, and the glyph bitmap bounding-box information > * is returned in OUT parameters. > * 1 if invalid HBF handle. > */ > /************************************************************/ > > PtrHBF_Octet HBF_GetBitmap( > IN HBF_Handle handle, > IN HBF_hzcode hanziCode ); > > /* Get the bitmap for the given hanzi code. > * > * RETURN the pointer to the bitmap of the hanzi; > * or the pointer to the bitmap of the DEFAULT_CHAR > * if invalid hanzi code; > * or NULL if invalid HBF handle. > */ > > /* N.B.: > * It is up to the application to show the bitmap properly within > * the FONTBOUNDINGBOX, if different from HBF_BITMAPBOUNDINGBOX. > */ > /************************************************************/ I think HBF_GetBitmap shouldn't return a bitmap upon invalid hanzi code, otherwise there is no way for the program to detect missing characters. On the other hand, if HBF_GetBitmap returns NULL on invalid code, the program can always get the DEFAULT_CHAR bitmap if it wants to. > A2.2 Desirable Application Programmer Interface (API) routines > > The API routines listed below are not required for an implementation > to be conformed to the HBF Standard v1.0. It is foresee that they > should be useful for some applications on some systems. To avoid > the proliferation of different routine names for such functions, > they are listed here, so that hopefully in future HBF Standard v2.0, > they will be supported using such routine names. > > /************************************************************/ > > PtrHBF_Octet HBF_GetBitmapRotated90( > IN HBF_Handle handle, > IN HBF_hzcode hanziCode ); > > /* Get the bitmap rotated for 90 degrees anticlockwise > * about the centre of the bitmap for the given hanzi code. > * RETURN the pointer to the bitmap of the hanzi; > * or the pointer to the bitmap of the DEFAULT_CHAR > * if invalid hanzi code; > * or NULL if invalid HBF handle. > * > * This routine may be implemented in assembly code for speed. > */ > /************************************************************/ Are these "desirable" routines enough? How about routine to inverse the hanzi bitmap? How about mirroring a bitmap horizontally/vertically? Routines to scale and merge bitmaps (they can be used to create missing characters, for example, I can use the "no" character and the "big" character to form the Cantonese(?) character "tiny, not big" ("no" over "big"))? How about rotating a bitmap in any angle? Are they plus the ones in this section really desirable? I doubt. HBF should be simple and minimal. Generic routines to manipulate bitmaps like the above and the following are most likely provided by the OS (like Windows, X11, Mac's QuickDraw) or the language graphics library anyway. Why duplicate them in the HBF API? > PtrHBF_Octet HBF_GetBitmapRotated180( > IN HBF_Handle handle, > IN HBF_hzcode hanziCode ); > > /* Get the bitmap rotated for 180 degrees anticlockwise > * about the centre of the bitmap for the given hanzi code. > * RETURN the pointer to the bitmap of the hanzi; > * or the pointer to the bitmap of the DEFAULT_CHAR > * if invalid hanzi code; > * or NULL if invalid HBF handle. What's the result if the bitmap is not squared? Should it be truncated or scaled? > * > * This routine may be implemented in assembly code for speed. > */ > /************************************************************/ I don't think it's appropriate to instruct the implementor in that level of detail. Moreover, with the advance in compiler and hardware technology today, I really doubt that you need to code these routines in assembly for speed. -Ricky From mcpong@uxmail.ust.hk Fri Mar 5 05:35:47 1993 Return-Path: Date: Fri, 5 Mar 93 18:46:28 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Ricky's comment on 0.2 Cc: mcpong@uxmail.ust.hk Status: RO > Date: Fri, 5 Mar 93 00:24:45 PST > From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Thank you very much for the detailed comment. My responses follow. Some may sound minor details, but I understand very often it depends on personal taste. Don't take it as strong opposition. I shall take the majority's opinions. No comment means OK either way. > > The format of HBF essentially follows X11R5 X Logical Font > > Description (XLFD) Conventions version 1.4 [1] and X11R5 > > Bitmap Distribution Format (BDF) version 2.1 [2]. > > > > A "simple HBF file" contains the minimum number of properties > > relevant to a fixed-width hanzi bitmap font. > > > > A "full HBF file" can have all the properties of a X11R5 font > > file, so that it can be converted easily to an X11R5 BDF file, > > say, using a utility program "hbf2bdf". > > > > Software running in non-X window system can simply use the > > "simple HBF file" format, and ignore any complicated properties > > specified in the "full HBF file". > > I wonder if it's necessary to explicitly distinguish two forms of HBF > files. I think it's suffice to only point out the required properties > and that all the other BDF properties are optional (then you can > significantly reduce the size of this HBF spec). Note that software > running in non-X window system don't care if the HBF file is simple or > full format, they only see the API and retrieve the properties needed. I have the PC programmers/users in mind as well when I wrote above. They may not know, nor want to know, the details of X11R5 BDF properties. For them, use of "simple HBF file" is sufficient. Imagine one day, a PC programmer first picks up the HBF Standard v1.0. If the Standard document doesn't distinguish the two, then he may need to read all the description of BDF properties in the document (and there actually isn't sufficient description in the document). On the other hand, if none of BDF properties is mentioned in this document, then the reader may not know what's BDF properties, and he may not be interested to dig up any X documents (as he is not an X programmer/user user anyway). The HBF Standard v1.0 is long; however, if any redundancy does not hurt the "completeness", then I prefer to keep the above (and some other relevant parts). How others think? IMHO, a deciding factor is: if someone first picks up this document, will he understand what it's all about; and know how to use HBF files (particularly as a programmer). > > A utility program "tofhbf" (not "shbf2fhbf", which has more > > than 8 letters and is not acceptable in MS-DOS) can convert > > Since HBF is a system independent spec, I think it's better not to > mention system dependent obscurities. Ideally, no system dependent specific information should be in a standard. However, by defining the name of the utility program, the same user using different systems doesn't have to learn probably different sets of commands (e.g. tofhbf, 2fhbf, shbf2fhbf, shbftofhbf, sHBF2fHBF {some systems have case sensitive commands}, etc.). Thus I prefer to mention the name explicitly in the document. If more people think we should delete such things, I'm ready to delete them. Now is one vote (me) for and one vote (Ricky) against :-) :-) > > (1) HBF_VERSION formatVersion > > How about calling it HBF_STARTFONT to be a true follower of BDF's > STARTFONT? Either is fine for me. HBF_VERSION is more suggestive for non-X user. > > A2.1 Basic Application Programmer Interface (API) routines > > > > The implementation can define the following (abstract) data types: > > > > HBF_Handle /* a handle to access a HBF */ > > Since it's an abstract data type, maybe the name like HBF_FONT would be > more appropriate. Either is fine for me. HBF_FONT may be more "abstract" while HBF_Handle is more implementation oriented. (though HBF means Hanzi Bitmap FONT already :-) > > HBF_Struct /* a structure of information parsed from HBF file */ > > I don't think there is any user-accessible fields in this struct, and > because HBF_FONT is an abstract data type, this shouldn't be exposed to > the API. I agree. Someone has proposed to have a struct (originally called "HBF_buff"??) to hold all the information. I'm not trying to dig up the mail record now to find out any rationale. I understand that HBF_Struct can provide provide faster access, if one wants to do so; but of course, it's violating the abstract data type (ADT) approach. (anyone still wants HBF_Struct?) > > HBF_Octet /* an 8-bit byte */ > > PtrHBF_Octet /* pointer to HBF_Octet sequence (a bitmap) */ > > > > [[ "PtrHBF_Octet" is more readable than "HBF_Octet *" ]] > > Personally I found the name Octet quite awkward. Why not call it byte? > Or better yet, BITMAP, which is defined clearly in this HBF spec. > > typedef char *BITMAP; "Byte" or "byte" is such a commonly used identifier that it may be defined by the application. I use "HBF_Octet" only for the reason to avoid possible duplicated declarations. Also Octet suggests it's an 8-bit thing -- it's a term from the network world. I can use "HBF_Byte"; note that it is different from "HBF_Bitmap". The former is a byte. The latter is a pointer to a byte sequence which is more implementation oriented. We can use HBF_Bitmap to hide this implementation fact; but this fact must be known by the programmer. Thus I use PtrHBF_Octect. (I prefer Ptr... instead of ...Ptr -- this is personal taste. My reason is that Ptr... is more readable: "Pointer to something".) > > HBF_HzCode /* a 16-bit hanzi code */ > > If hanzi code is an abstract type, then you better define API routines > to access/retrieve the 1st and 2nd bytes, etc. A struct or unsigned > integer impementation has quite different implications to the > application programmers. I propose to define HBF_HzCode to be a minimum > 16-bit unsigned integer. We can define more API: (may be functions or macros) HBF_Octet HBF_HzCodeByte1( HBF_HzCode hc ); HBF_Octet HBF_HzCodeByte2( HBF_HzCode hc ); ^^^^^^^^^ or globally changed to HBF_Byte if the consensus is so. > > A sample implementation in Unix/C can be: > > ... > > char* HBF_GetProperty( > > IN HBF_Handle handle, > > IN char * propertyName ); > > > > /* Get the property of the given propertyName. > > * > > * RETURN the character string as if appeared after the keyword > > * of the property in the property line in the HBF file, > > * starting with a non-space character, with only one blank > > * character separating each pair of tokens in the string, > > * and with no trailing blanks; > > * or NULL if invalid HBF handle or invalid propertyName. > > * > > * The calling routine should free the returned string after use. > > I think you meant "should NOT free" here, otherwise the HBF library has > to make a copy of the property value string on each inquiry. The > returned property value should be treated as constant anyway. I really mean "should free". I am thinking that the HBF_Handle internal structure **may** not store the lines of properties exactly as specified in the HBF file. Thus, HBF_GetProperty may have to construct back the string in the returning format (like squeeze out extra blanks, remove leading & trailing blanks). To avoid memory leakage, the application should free it. As modern CPU runs fast enough, allocate an "extra" copy of string doesn't cause much, & also, this function should not be called frequently. (The application can forget to free it; actually won't waste much :-) If not, then the specification dictates(?) the implementation that the property strings must be kept in ready-to-return form. > > * In Standard v1.0, only properties in simple HBF file are valid. > > Why put that restriction? This is for simple implementation which can claim conformance to Standard v1.0. If not, then it seems that it is necessary to support all X11R5 BDF -- which seems to be not very appropriate for PC. Also, the full HBF properties are only really useful in X environment. (Font server is an even further away business.) > > int HBF_GetFontBoundingBox( > > IN HBF_Handle handle, > > OUT unsigned int *width, > > OUT unsigned int *height, > > OUT unsigned int *xDisplacement, > > OUT unsigned int *yDisplacement ); > > > > /* Get the font bounding-box information for a given HBF. > > * > > * RETURN 0 if OK, and the font bounding-box information > > * is returned in OUT parameters. > > * 1 if invalid HBF handle. > > */ > > /************************************************************/ > > It seems better to have the function return 0 for error and non-zero > otherwise, so that the programmer can simply use the ! operator to test > for error (like many UNIX/C library routines). I was thinking of avoiding [typing] the "!", i.e.: if ( HBF_GetFontBoundingBox(...) ) { Error } I now see it's not so readable. It should be changed as suggested by Ricky. > > ... > > PtrHBF_Octet HBF_GetBitmap( > > IN HBF_Handle handle, > > IN HBF_hzcode hanziCode ); > > > > /* Get the bitmap for the given hanzi code. > > * > > * RETURN the pointer to the bitmap of the hanzi; > > * or the pointer to the bitmap of the DEFAULT_CHAR > > * if invalid hanzi code; > > * or NULL if invalid HBF handle. > > */ > > > > /* N.B.: > > * It is up to the application to show the bitmap properly within > > * the FONTBOUNDINGBOX, if different from HBF_BITMAPBOUNDINGBOX. > > */ > > /************************************************************/ > > I think HBF_GetBitmap shouldn't return a bitmap upon invalid hanzi code, > otherwise there is no way for the program to detect missing characters. > On the other hand, if HBF_GetBitmap returns NULL on invalid code, the > program can always get the DEFAULT_CHAR bitmap if it wants to. That's what I understand "DEFAULT_CHAR" supposed to mean. The following is in HBF Standard v1.0 and is adopted from the X11R5 document (except that the word "optional" before unsigned integer was omitted, as suggested by F.F.Lee(?) ). (9) DEFAULT_CHAR defaultCharCode defaultCharCode: an unsigned integer specifying the hanzi code to be used when an attempt is made to display an undefined or ^^^^^^^^^ non-existent glyph in the font. ^^^^^^^^^^^^ I regard that it means invalid hanzi code. > > A2.2 Desirable Application Programmer Interface (API) routines > > > > ... > > > > PtrHBF_Octet HBF_GetBitmapRotated90( > > IN HBF_Handle handle, > > IN HBF_hzcode hanziCode ); > > > > /* Get the bitmap rotated for 90 degrees anticlockwise > > * about the centre of the bitmap for the given hanzi code. > > * RETURN the pointer to the bitmap of the hanzi; > > * or the pointer to the bitmap of the DEFAULT_CHAR > > * if invalid hanzi code; > > * or NULL if invalid HBF handle. > > * > > * This routine may be implemented in assembly code for speed. > > */ > > /************************************************************/ > > Are these "desirable" routines enough? Maybe not enough, as suggested by the following examples. > How about routine to inverse the > hanzi bitmap? How about mirroring a bitmap horizontally/vertically? > Routines to scale and merge bitmaps (they can be used to create missing > characters, for example, I can use the "no" character and the "big" > character to form the Cantonese(?) character "tiny, not big" ("no" over > "big"))? How about rotating a bitmap in any angle? These can be left for future HBF Standard vX.Y, if DEEMED NECESSARY. See below why 2 of which, HBF_GetBitmapRotated90 & HBF_GetBitmapRotated270, are deemed necessary. > Are they plus the ones in this section really desirable? I doubt. HBF > should be simple and minimal. Generic routines to manipulate bitmaps > like the above and the following are most likely provided by the OS > (like Windows, X11, Mac's QuickDraw) or the language graphics library > anyway. Why duplicate them in the HBF API? Actually at first I only try to mention HBF_GetBitmapRotated90 & HBF_GetBitmapRotated270 They are for allowing bitmaps for dot-matrix printers, and to provide the API routines ready for packages like BYX 1.1 to use HBF fonts instead of column-major bitmap font files. If we have these, then such packages should be easy to convert to use HBF fonts. (No excuse to not changing? :-) :-) The reason for mentioning as an Appendix is to avoid proliferation of different routine names for such functions, as mentioned at the start of the Appendix: The API routines listed below are not required for an implementation to be conformed to the HBF Standard v1.0. It is foresee that they should be useful for some applications on some systems. To avoid the proliferation of different routine names for such functions, they are listed here, so that hopefully in future HBF Standard v2.0, they will be supported using such routine names. ... > > PtrHBF_Octet HBF_GetBitmapRotated180( > > IN HBF_Handle handle, > > IN HBF_hzcode hanziCode ); > > > > /* Get the bitmap rotated for 180 degrees anticlockwise > > * about the centre of the bitmap for the given hanzi code. > > * RETURN the pointer to the bitmap of the hanzi; > > * or the pointer to the bitmap of the DEFAULT_CHAR > > * if invalid hanzi code; > > * or NULL if invalid HBF handle. > > What's the result if the bitmap is not squared? Should it be truncated > or scaled? Rotated90 & Rotated270 should be there, then I think: to be "complete" to a certain extent, why not mention Rotated180 as well :-) BTW, if the bitmap is rectangle, the returned bitmap (byte sequence) will be a rotated rectangle about the centre of the original one. > > * This routine may be implemented in assembly code for speed. > > */ > > /************************************************************/ > > I don't think it's appropriate to instruct the implementor in that level > of detail. Moreover, with the advance in compiler and hardware > technology today, I really doubt that you need to code these routines in > assembly for speed. It's just a reminder. I put this line in after reading one of the mail suggesting that both Intel & Motorola chips have special instruction for bitmap rotation. :-) Some may be concerned about the speed of rotating bitmap vesus extra font file space. Thus I add this line, hoping to convince that speed is not a problem. :-) This line should be taken out, ideally from a pure specification point of view. (On the other hand, I sometimes specifying/suggesting some implementation details doesn't hurt :-) I shall abide to the majority's opinion. > -Ricky One's again; thank you very much for the detailed comment (the 1st so far :-). mcpong From CAI@neurophys.wisc.edu Fri Mar 5 10:42:57 1993 Return-Path: Date: Fri, 5 Mar 93 10:36 CST From: CAI@neurophys.wisc.edu Subject: HBF v0.2 To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O Thank you Mr. Pong for drafting HBF, I really appreciate your work. It has been silent these days except that of Ricky's. I suppose most people are satisfied with V0.2. Actually, I think the simple HBF file part is quite good now. Since I do not have experience with X windows, I can not say anything about the full HBF file part. Back to Mr. Pong's response to Ricky's comment, I support Mr. Pong's choice in all those things not related to API (actually in some cases there are no contradictions between Pong and Ricky, in those cases, I support both). I have not considered API carefully and some of them are also bejond by ability. One more thing: is is necessary to quote the bitmap file name like "cclib.j24" ? I fell it need a little more work to get rid of the " ". Can we simple use cclib.j24? Or there is a strong reason behind it. Regards, Yidao Cai From mcpong@uxmail.ust.hk Fri Mar 5 19:21:41 1993 Return-Path: Date: Sat, 6 Mar 93 09:12:28 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: xiaofei's comment on 0.2 Status: O > Date: Fri, 5 Mar 93 18:52:56 CST > From: xiaofei@ifcss.org (XiaoFei Wang) > > You can made two files, one is standard, one is to aid the understanding > of the standard. That's a good idea. The Ada language standard was released for comment with a separate "book" on design rationale. I intend to have the rationale documented as well. One way is to put in footnotes of the relevant reasons. Another is to have a separate document of the retionale. In term of completeness, using a combined file (documents) of simple HBF & full HBF file format descriptions has its advantage. Breaking into 2 separate documents also have advantages; but will require more time to do so. In term of work scheduling, I would prefer to have the details of the standard documented AND a sample implementation ready first. Then we can polish the "presentation". mcpong From simpson@math.psu.edu Fri Mar 5 22:09:39 1993 Return-Path: From: Stephen G Simpson Date: Fri, 5 Mar 93 23:01:43 -0500 To: soft-authors@ifcss.org Subject: rotation and reflection Status: O Once again, thank you M. C. Pong for your excellent work on HBF draft 0.2. I especially appreciate your care in the section on FONTBOUNDINGBOX versus HBF_BITMAPBOUNDINGBOX, with all its careful explanations and detailed examples. I am very happy with the outcome of that discussion. > The implementation of the standard will alleviate the problem > that a certain software is usually distributed with its own > hanzi bitmap file(s). This reduces the need to keep different > formats of the same hanzi bitmap fonts, thus reducing the disk > space requirement.... In accordance with this goal of saving disk space, I would like to once again plead for HBF to take account of the fact that at least one important Hanzi bitmap fonts are stored sideways, for example ZIKU24 in Byx 1.1. I now think we can do this very simply, without adding significant complexity to either the HBF standard or its implementation. My proposal is to have two additional keywords (optional or required, I have no strong preference), HBF_BITMAP_ROTATE with possible values 0, 90, 180, and 270, and HBF_BITMAP_REFLECT with possible values 0 and 1. The usual or default values would be of course 0 and 0, so an HBF file (simple or full) would typically contain or omit the lines HBF_BITMAP_ROTATE 0 HBF_BITMAP_REFLECT 0 This would be case for CCLIB fonts, ET fonts, etc. But the HBF file for ZIKU24 would contain HBF_BITMAP_ROTATE 270 HBF_BITMAP_REFLECT 1 indicating that each bitmap wants to be to be rotated 270 degrees counterclockwise and then reflected in the vertical axis, in order to restore it to its normal upright position. The decision of whether and how to to transform the bitmap is left to the application. For instance, a dot matrix printing application (such as Byx's DAYIN24, using ZIKU24) may well want to leave the bitmap as it is. And that's all there is to my proposal! It is very simple! It involves no work whatsoever! My proposal has nothing at all to do with the difficult issue of vertical printing. (Vertical printing is a difficult issue, because some glyphs such as brackets may want to be rotated for vertical printing, while Hanzi do not want to be rotated). Note also that my proposal has nothing to do with M. C. Pong's proposed API calls HBF_GetBitmapRotated90(...), etc. In my proposal, the rotation and/or reflection is left to be performed or not to be performed by the calling application, as illustrated above. My keywords HBF_BITMAP_ROTATE and HBF_BITMAP_REFLECT are essentially just stylistic properties, in the vein of FAMILY_NAME and ADD_STYLE_NAME. They provide extremely useful information about the contents of the bitmap files, but they do not impose any implementation requirements. I think that my proposal would significantly increase the flexibility of the HBF standard, without significantly increasing its complexity, or the difficulty of using it, or the difficulty of implementing it. [ One technical caveat concerning my proposal. Rotations and reflections do not commute! The order is important! In the above example, the ZIKU24 bitmaps can be rotated 270 degrees counterclockwise and then reflected in the vertical axis. But, the same effect can be achieved by first reflecting in the vertical axis and then rotating counterclockwise by 90 (not 270) degrees. Or, the same effect can also be achieved by merely reflecting in a diagonal axis which runs from upper left to lower right. So we have to take care to specify the convention: first counterclockwise rotation by HBF_BITMAP_ROTATE degrees, then reflection in the vertical axis if HBF_BITMAP_REFLECT is set to 1. Any reasonable convention would do the job, but we must be consistent. ] -- Stephen G. Simpson From simpson@math.psu.edu Fri Mar 5 22:09:43 1993 Return-Path: From: Stephen G Simpson Date: Fri, 5 Mar 93 23:02:26 -0500 To: soft-authors@ifcss.org Subject: small comments on HBF draft standard 0.2 Status: O A couple more comments on the HBF draft standard 0.2. > Each property is introduced by a keyword spelt as a string of > upper case letters. The past participle of "spell" is sometimes spelt "spelled" but it is also sometimes spelled "spelt", so either one is OK. :-) > If a HBF keyword is made up from more than one English word, > the words are separated by "_" for better readability. > Note that "_" is used as word separator in some X11R5 BDF keywords > but not in others, whereas "_" is used consistently in HBF keywords. > > ... > > (4) HBF_BITMAPBOUNDINGBOX w h xd yd Whoops! In accordance with the previous statement this has to be (4) HBF_BITMAP_BOUNDING_BOX w h xd yd thus making an exceptionally long keyword even longer. Actually I don't think the _'s are so important, but if we are going to use them, we should do so consistently. -- S. Simpson From ygz@cs.purdue.edu Fri Mar 5 22:56:33 1993 Return-Path: To: soft-authors@ifcss.org Subject: Re: rotation and reflection In-Reply-To: Your message of Fri, 05 Mar 1993 23:01:43 -0500. <9303060401.AA24703@boole.math.psu.edu> Date: Fri, 05 Mar 1993 23:49:00 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O Hi, In message <9303060401.AA24703@boole.math.psu.edu> Stephen G Simpson writes > In accordance with this goal of saving disk space, I would like to > once again plead for HBF to take account of the fact that at least one > important Hanzi bitmap fonts are stored sideways, for example ZIKU24 > in Byx 1.1. I now think we can do this very simply, without adding > significant complexity to either the HBF standard or its > implementation. > > My proposal is to have two additional keywords (optional or required, > I have no strong preference), HBF_BITMAP_ROTATE with possible values > 0, 90, 180, and 270, and HBF_BITMAP_REFLECT with possible values 0 > and 1. The usual or default values would be of course 0 and 0, so an > HBF file (simple or full) would typically contain or omit the lines > > HBF_BITMAP_ROTATE 0 > HBF_BITMAP_REFLECT 0 > > This would be case for CCLIB fonts, ET fonts, etc. But the HBF file > for ZIKU24 would contain > > HBF_BITMAP_ROTATE 270 > HBF_BITMAP_REFLECT 1 > > indicating that each bitmap wants to be to be rotated 270 degrees > counterclockwise and then reflected in the vertical axis, in order to > restore it to its normal upright position. The decision of whether > and how to to transform the bitmap is left to the application. For > instance, a dot matrix printing application (such as Byx's DAYIN24, > using ZIKU24) may well want to leave the bitmap as it is. > > And that's all there is to my proposal! It is very simple! It > involves no work whatsoever! I am not sure if I'll vote for adding it now or leaving it for later version. But if we elect to add it, I will suggest to use only one keyword, say HBF_BITMAP_ORIENTATION, which indicates "orientation" of a bitmap when it is read from the file. The default, and for most fonts, HBF_BITMAP_ORIENTATION upright For ZIKU24, HBF_BITMAP_ORIENTATION sideway Although we can define all possible combination (at most 8 of them), but how many times have you seen a bitmap font file that is 180 degree rotated and also reflected? Alternative names for the orientations I can think of are "column-wise", "row-wise", which specify how a bitmap is stored in a byte stream. Note that the semantics of HBF_BITMAPBOUNDINGBOX may have changed in a sideway font. For example, a 15x16 font will required padding in a "row-wise" orientation, but not in the "column-wise". --ygz From simpson@math.psu.edu Sat Mar 6 00:12:09 1993 Return-Path: From: Stephen G Simpson Date: Sat, 6 Mar 93 01:03:16 -0500 To: soft-authors@ifcss.org In-Reply-To: <199303060449.AA00632@ector.cs.purdue.edu> Subject: Re: rotation and reflection Status: O I wrote: > > My proposal is to have two additional keywords (optional or required, > > I have no strong preference), HBF_BITMAP_ROTATE with possible values > > 0, 90, 180, and 270, and HBF_BITMAP_REFLECT with possible values 0 > > and 1. ygz@cs.purdue.edu (Yongguang Zhang) wrote: > I am not sure if I'll vote for adding it now or leaving it for later > version. I vote for adding it soon, but if not, let's keep it in mind for later versions. > But if we elect to add it, I will suggest to use only > one keyword, say HBF_BITMAP_ORIENTATION, which indicates > "orientation" of a bitmap when it is read from the file. > > The default, and for most fonts, > > HBF_BITMAP_ORIENTATION upright > > For ZIKU24, > > HBF_BITMAP_ORIENTATION sideway > > Although we can define all possible combination (at most 8 of them), > but how many times have you seen a bitmap font file that is 180 > degree rotated and also reflected? Never, but it could happen, and it would cost very little effort now to provide for all 8 possibilities. If two keywords seem cumbersome, how about just one keyword with two parameters? Maybe something like this: HBF_ORIENTATION rotate reflect For example HBF_ORIENTATION 0 0 (for CCLIB fonts, ET fonts, ...) HBF_ORIENTATION 270 1 (for ZIKU24 and ZIKU16) This is essentially equivalent to my original proposal, and I like it just as well. (But Yongguang is also correct -- in practice only two possibilities occur, so the immediate need is for only one parameter with two possible values. This route would also be reasonable.) > Note that the semantics of HBF_BITMAPBOUNDINGBOX may have changed in > a sideway font. For example, a 15x16 font will required padding > in a "row-wise" orientation, but not in the "column-wise". Yes. And therefore the number of bytes per bitmap will be different for these two cases. As to the semantics of HBF_BITMAPBOUNDINGBOX and FONTBOUNDINGBOX, it seems to me that they should always refer to the upright or "row-wise" bitmap, otherwise the semantics of xd and yd get very confusing. So the formula for the number of bytes in a bitmap will be ((w+7)/8)*h if rotate is 0 or 180, w*((h+7)/8) if rotate is 90 or 270. As before, this will not add to the difficulty of implementation. -- S. Simpson From CAI@neurophys.wisc.edu Sat Mar 6 10:57:45 1993 Return-Path: Date: Sat, 6 Mar 93 10:47 CST From: CAI@neurophys.wisc.edu Subject: Re: rotation and reflection To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O I vote against putting it in V1.0, but we can consider to add it in later versions. My reason is quite simple: make HBF as simple as possible. If there is indeed a need for it, as we'll find it out later, we can put it on. If we put it on, we have to check this proverty as well if we want to match a font. I wonder if other softwares besides BYX use this format. Can Mr. Simpson contact the author of BYX about this? May be he is willing to change. By the way, I do not consider BYX a great software (I mean v1.1, later versions are called XLBR and are not free) as compared to others, although I still use it for simple editing. Maybe Mr. Simpson can switch to other softwares (I reccommand NJSTAR). I know it is hard to make this decision and this why I still use BYX for simple purposes. Just one vote. Regards, Yidao From simpson@math.psu.edu Sat Mar 6 11:51:09 1993 Return-Path: From: Stephen G Simpson Date: Sat, 6 Mar 93 12:44:15 -0500 To: soft-authors@ifcss.org In-Reply-To: <23030610471367@neurophys.wisc.edu> Subject: Re: rotation and reflection Status: O CAI@neurophys.wisc.edu writes: > I vote against putting it in V1.0, but we can consider to add it in later > versions. > ... > If we put it on, we have to check this proverty as well if we want to match > a font. I don't understand what is meant here by "matching a font". Under my proposal, application software is free to ignore the rotation and reflection properties of fonts, i.e. to assume rotate = reflect = 0. That is up to the application software developer to decide. > I wonder if other softwares besides BYX use this format. I don't know of any software other than BYX that uses sideways bitmaps. However, BYX uses them for a very good reason -- the sideways presentation corresponds better to the data stream for a dot matrix printer. > Can Mr. Simpson > contact the author of BYX about this? May be he is willing to change. I refuse to do this. I think it would be wrong for HBF to ask a software developer to switch to fonts that are less suitable for his purpose. The idea of HBF is to make life easier for software developers, not harder. If HBF cannot do this, HBF will die. We should make HBF sufficiently flexible to accommodate the Hanzi bitmap fonts (and ways of using fonts) that are actually used in the real world. BYX 1.1 is extremely popular software, therefore HBF should accommodate the fonts that are used in BYX. > By the way, I do not consider BYX a great software (I mean v1.1, > later versions are called XLBR and are not free) as compared to > others, although I still use it for simple editing. Maybe Mr. > Simpson can switch to other softwares (I reccommand NJSTAR). I > know it is hard to make this decision and this why I still use BYX > for simple purposes. The purpose of HBF is certainly not to judge the overall merit of application software packages, nor to ask users to stop using certain software just because HBF doesn't like it. We cannot demand or expect that software users will conform to the needs of HBF. Rather, HBF should conform to the needs of users. -- S. Simpson From yawei@bronze.ucs.indiana.edu Sat Mar 6 13:27:13 1993 Return-Path: Date: Sat, 6 Mar 1993 14:17:28 -0500 From: ~{QG9p~} To: simpson@math.psu.edu, soft-authors@ifcss.org Subject: Re: rotation and reflection Status: O I suspect (no hard data here) that most Chinese software running on the PC and supports dot matrix printing uses sideway fonts. Especially if the program is written in a high level language. They'd either come with a sideway font or generate a sideway font at installation time. ZWDOS v2.2, however, need not use a sideway font. It generates the sideway font at run time and still prints at fast speed. (I do plan to have ZWDOS uses sideway fonts from other applications for its display purpose though. It will rotate them back to upright position at run time.) The point is that HBF should be versatile enough to describe most of the fonts that are currently available. The programmer, of course, is free to use only a subset of it at a time. If HBF doesn't describe rotated fonts, then I can't use HBF and still carry out the above plan of utilizing existing rotated fonts in ZWDOS without making nonstandard extensions to HBF. This is just one programmer's point of view. I also support the principle of keeping things simple. But adding description for rotated fonts does not neccessarily increases HBF's complexity. Ya-Gui From lee@fritter.Stanford.EDU Sun Mar 7 03:42:38 1993 Return-Path: Date: Sun, 7 Mar 93 01:39:31 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: HBF_ORIENTATION Status: O Although I am still NOT convinced that supporting more than one bitmap orientation ("upright") is a good idea, I am now willing to compromise and even offer a proposal. This time rather than borrowing good ideas from BDF, we borrow the ideas from TIFF. The two tag fields relevant to our purpose are "FillOrder" and "Orientation". Following are the relevant excerpts from Tag Image File Format (TIFF) Specification Revision 5.0: ============================================================================= No Longer Recommended [[yes, these fields are no longer recommended as stated in the spec]] [[It may also be no longer recommended in future HBF spec :-) ]] FillOrder Tag = 266 (10A) 1 = most significant bits of the byte are filled first. 2 = least significant bits are filled first. Default is 1. [[This is quoted for completeness. Everybody agrees that FillOrder is always 1, and hence no need to explicitly specify it in HBF, right? ]] Orientation Tag = 274 (112) 1 = The 0th row represents the visual top of the image, and the 0th column represents the visual left hand side. 2 = The 0th row represents the visual top of the image, and the 0th column represents the visual right hand side. 3 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual right hand side. 4 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual left hand side. 5 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual top. 6 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual top. 7 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual bottom. 8 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual bottom. Default is 1. ============================================================================= [["upright" is 1, and I believe the so-called "sideway" is 5, right?]] Rather than inventing 8 names for orientation, I would suggest to simply follow TIFF's convention and use the numbers form 1 to 8 as above. There are actually 3 kinds of "objects" we are dealing with: 1. 2-D visual (display) in terms of x-y coordinates 2. 2-D bitmap arrays in terms of row and column numbers 3. 1-D (linear) sequences of bytes Figures 1 and 2 show the mappings among them. ----------------------------------------------------------------------------- 0---> | ncol v --------- --------- | | orientation | | nrow | | ------> wy | | | | | | --------- ^ --------- | wx 0--> Fig. 1 ----------------------------------------------------------------------------- storage 2-D matrix (row, col) ----------> row-major order 1-D array mapping Fig. 2 ----------------------------------------------------------------------------- There are many ways to define the mappings. There are 8 possible orientation mappings. The relationship among the parameters of (1) and (2) are listed in the following table. (L=Left,R=right,T=top,B=bottom) orientation 0th row 0th column nrow ncol 1 T L wy wx 2 T R wy wx 3 B R wy wx 4 B L wy wx 5 L T wx wy 6 R T wx wy 7 R B wx wy 8 L B wx wy This way we can always define the storage mapping in row-major order regardless of the orientation. The definition about how to pad bits to integral number of bytes remains the same as described in draft 0.2. What about bounding boxes information? Bounding boxes refer to visual information, and hence remain the same regardless of the orientation. For example: COMMENT 1. cclib.24 HBF_BITMAP_BOUNDING_BOX 24 24 0 -2 HBF_ORIENTATION 1 COMMENT 2. ziku.24 (cclib.24 rotated and reflected?) HBF_BITMAP_BOUNDING_BOX 24 24 0 -2 HBF_ORIENTATION 5 COMMENT 3. eten (a row is a horizontal line) HBF_BITMAP_BOUNDING_BOX 16 15 0 -1 HBF_ORIENTATION 1 COMMENT 4. eten (rotated-reflected) (a row is a vertical line) HBF_BITMAP_BOUNDING_BOX 16 15 0 -1 HBF_ORIENTATION 5 Note that the values of the (), () fields are the same in the last two cases, because they are visual information. In case 3, nrow = wy, ncol = wx. In case 4, nrow = wx, ncol = wy. The line HBF_ORIENTATION is optional, with default = 1 ("upright"). For orientation = 1 bitmap files, it is recommended that this line to be omitted (in the event that HBF_ORIENTATION will be no longer recommended in future version of HBF). Notice that it is the responsibility of the application to call something like HBF_GetProperty("HBF_ORIENTATION") to determine the orientation and make the appropriate adjustments (such as assigning values to nrow, ncol) to interpret the bitmap returned by HBF_GetBitmap(). It is up to the application to decide whether it needs to transform the returned bitmap. HBF_GetBitmap() always returns the bitmap with nrow and ncol in row-major order. Whether nrow is wy or wx, and the order of scanning depends on the orientation. Yes, this scheme is definitely more complicated than the simple scheme supporting only one orientation. But you have to pay for what get. Actually, for applications which do not want to deal with this issue, and just want to deal with "upright" bitmaps, they can simply check whether the value of HBF_ORIENTATION is 1. Summary: (1) add one more optional property: HBF_ORIENTATION (2) distinguish the wx,wy and ncol,nrow concepts and re-interpret the structure / ordering of the result returned by HBF_GetBitmap(). Caveat: Steven Simpson has suggested a solution to the orientation problem. We seem to agree that these additional keywords are property indicators and that it would NOT require the library implementing the API to perform any transformation such as rotation or reflection. However, I do want to point out again that these are not "stylistic" properties as FAMILY_NAME, ADD_STYLE_NAME are, because they are essential to the interpretation of the data structure of the bitmaps. ygz pointed out the possible issues involved, and I agree with him that with these "upright" and "sideway" stuff, it is bound to cause some if not more confusion when we are dealing with non-square bitmaps such as 16x15 (or 15x16 ?? :-). I always doubt whether this extra flexibility will cost us more than we want to pay for in the long term. At least in the short term, it gives us a longer and perhaps less understandable HBF specification document. Fung F. Lee From lee@fritter.Stanford.EDU Sun Mar 7 18:34:55 1993 Return-Path: Date: Sun, 7 Mar 93 16:32:13 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: [yawei@bronze.ucs.indiana.edu: Re: HBF_ORIENTATION] Status: O With yawei's permission, I am forwarding the following message. -Fung Date: Sun, 7 Mar 1993 11:06:27 -0500 From: ~{QG9p~} To: lee@fritter.stanford.edu Subject: Re: HBF_ORIENTATION I think this proposal looks great. Again, I'd like to restate that the programmer is always free to ignore these parameters (perhaps we should make these parameters as "optional" meaning their support is not mandatory.) I for one will probably only support orientations 1 and 5 ( I don't see any reason for the existence of other orientations now). Also FillOrder will probably always be 1 but that too can remain as an optional parameter. From mcpong@uxmail.ust.hk Sun Mar 7 19:27:30 1993 Return-Path: Date: Mon, 8 Mar 93 09:22:32 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: HBF_ORIENTATION Status: O I prefer to **support upright bitmap only** in HBF Standard v1.0 (i.e. I object to adding the property HBF_ORIENTATION or the like). Reasons: ------- (1) So far, the request to incorporate sideway bitmap fonts is to describe ZIKU which is used in BYX 1.1. I haven't seen the fonts of ZIKU, but it seems that it's more or less the same as CCLIB, except in terms of format. If BYX DOESN'T change to use HBF format, even if the HBF Standard accommodates sideway bitmap, it doesn't help. If BYX DOES change to use HBF format, with the provision of API routines (probably with the additional non-standard-strict-comforming routines HBF_GetBitmapRotated90() & HBF_GetBitmapRotated270(), BYX should be easily changed to use upright bitmap only. (Anyway, BYX has to convert between upright bitmap and sideway bitmap in order to display and print, respectively.) The allowance of non-upright hanzi bitmap font in HBF Standard v1.0 may be mis-interpreted as that we don't want a future hanzi bitmap font to be in 1 set of bitmap files only PER STYLE AND BITMAP SIZE. That is, the use/support of two formats of the "same" font (only differ in format) should be discouraged. By only supporting upright bitmap in the Standard v1.0, the programmers have a chance to see if v1.0 really serves the purpose and their need. If really not, then we can have HBF Standard v2.0, which is upgraded based on experience which we have not forseen now. [[ IMHO, not yet matured at this stage to support non-upright bitmap. ]] (2) F.F.Lee has summarized well an alternative proposal to use TIFF to describe non-upright bitmaps. The TIFF format is difficult to describe in a simple document. Now draft v0.2 is 1471 lines (including the last Appendix of "rationale for HBF_CODE_RANGE" which has about 110 lines): > wc HBF.std 1471 7321 50077 HBF.std (Adding the description of bounding box has increased it for several hundred lines.) Lee's mail related to TIFF and HBF is from 140 lines to about 200 lines (depending on what is included or excluded). We may have to add more than 200 lines to describe HBF_ORIENTATION or the like, hopefully that would be clear enough to "some" programmers who are interested in this part. It seems currently "some" is only a small no. (from 0 to several :-) and if they use HBF, there is an alternative to deal with the issue. [[ which is better in the spirit of HBF, IMHO ]] mcpong From Ricky.Yeung@Eng.Sun.COM Sun Mar 7 22:05:54 1993 Return-Path: Date: Sun, 7 Mar 93 19:03:36 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: soft-authors@ifcss.org Subject: A simple experiment on rotation speed Content-Length: 0 Status: RO I just did a quick-n-dirty experiment on my obsoleted 386 PC with a 19ms seek time HD. The program was written in C, compiled with the Microsoft C compiler. I only did some simple and clear optimizations on the C source. Case 1: Save 7500 24x24 bitmaps in memory and rotate them. Result: several seconds to complete the entire rotation. (Notice that if you have sufficient memory, this is a one time cost!) Case 2: (Extreme Case) Not store the bitmaps in memory, disable all disk cache, and EVERYTIME use fseek/fread to access the bitmap. Result 1. Without rotation, it took about 66 seconds to just fseek/fread 7500*3=22500 bitmaps (which is way more than the size of a HXWZ document, I think). Result 2. With rotation added in, it took about 10% extra time. (BTW, on my SparcStation 2 and on a DECstation 5000, both cases finished in a couple seconds or so.) Although my experiment is by no means conclusive, I really doubt you need to code in assembly in order to achieve desired performance on bitmap rotation, as suggested below. More importantly, I really question the need to rearrange cclib bitmap for speed. I would rather pay the seemingly negligible (consider the slow printer speed) rotation cost only when I want to print rather than keeping two copies of bitmaps for the same font: one for printing and one for display. -Ricky From the draft: > /************************************************************/ > > PtrHBF_Octet HBF_GetBitmapRotated90( > IN HBF_Handle handle, > IN HBF_hzcode hanziCode ); ... > * This routine may be implemented in assembly code for speed. > */ > /************************************************************/ > > Date: Thu, 25 Feb 1993 15:57:03 -0500 > From: ~{QG9p~} > Content-Length: 1008 > > > >Yes, the "HINT" of the reason why BYX chose a different bitmap format > >(non-row-major) is perhaps best given by Jiang: > > > Actually, that's not true. ZIKU24 is amost straight from CCDOS > with no or little modifications. The reason it is sideways (actually > the mirror image of the upright fonts rotated 90 degrees) is > because it is the so called "print font" in CCDOS and Byx -- > and it was arranged to co-incide with the data stream order of > popular dot matrix printers. > > Rotating fonts with a high level language (or even a semi-high level > language like "C") is very expensive. When you install Byx 1.1, it > spends considerable time to generate a rotated version of its ZIKU16 > for printing purpose. [On the other hand, font rotation in Intel or > Motorola's assembly languages is quite easy and inexpensive.] > > I think HBF should either include provisions for non-upright > fonts or leave another room for future expansions to include them. From mcpong@uxmail.ust.hk Mon Mar 8 01:11:37 1993 Return-Path: Date: Mon, 8 Mar 93 15:05:43 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF_GetBitmapRotatedXXX() Status: O > Date: Sun, 7 Mar 93 19:03:36 PST > From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) > Subject: A simple experiment on rotation speed > > ... > > Although my experiment is by no means conclusive, I really doubt you > need to code in assembly in order to achieve desired performance on > bitmap rotation, as suggested below. > From the draft: > > > /************************************************************/ > > > > PtrHBF_Octet HBF_GetBitmapRotated90( > > IN HBF_Handle handle, > > IN HBF_hzcode hanziCode ); > ... > > * This routine may be implemented in assembly code for speed. > > */ > > /************************************************************/ I am happy to remove the line of "may be implemented in assembly code". Nevertheless, I think keeping HBF_GetBitmapRotated90() and HBF_GetBitmapRotated270() is appropriate -- they will not be a requirement for conformance to HBF Standard v1.0; but only deemed as desirable. > More importantly, I really > question the need to rearrange cclib bitmap for speed. I would rather > pay the seemingly negligible (consider the slow printer speed) rotation > cost only when I want to print rather than keeping two copies of bitmaps > for the same font: one for printing and one for display. > > -Ricky I agree with this. That is, not supporting non-upright bitmap in Standard v1.0. mcpong From Ricky.Yeung@Eng.Sun.COM Mon Mar 8 10:59:36 1993 Return-Path: Date: Mon, 8 Mar 93 04:00:51 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: soft-authors@ifcss.org Cc: Ricky.Yeung@Eng.Sun.COM In-Reply-To: Dr. PONG Man Chi's message of Fri, 5 Mar 93 18:46:28 HKT <9303051046.AA14295@uxmail.ust.hk> Subject: Re: Ricky's comment on 0.2 Content-Length: 14763 Status: O Since there are simple and full HBF files, do you allow something in-between, not-so-simple-but-not-really-full HBF file? :-)) > > I wonder if it's necessary to explicitly distinguish two forms of HBF > > files. I think it's suffice to only point out the required properties > > and that all the other BDF properties are optional (then you can > > significantly reduce the size of this HBF spec). Note that software > > running in non-X window system don't care if the HBF file is simple or > > full format, they only see the API and retrieve the properties needed. > > I have the PC programmers/users in mind as well when I wrote above. > They may not know, nor want to know, the details of X11R5 BDF properties. That's exactly my point, they don't care about X11R5 BDF properties. > For them, use of "simple HBF file" is sufficient. All they need to do is to read the HBF document, which hopefully would only contain explanations (I hope) about the HBF specific properties. In their programs, they only need to retrieve those HBF specific properties through the sample API routine HBF_GetProperty. They don't need to understand ANY X11R5 BDF property mentioned in the current "full" HBF at all. If they DO need to read the HBF header file, they can simply skip those properties that are not mentioned in the HBF document. Isn't that nice? :-) > Imagine one day, a PC programmer first picks up the HBF Standard v1.0. > If the Standard document doesn't distinguish the two, then he may need > to read all the description of BDF properties in the document (and > there actually isn't sufficient description in the document). No, I'm not saying you don't need to distinguish the two, but I'm saying that a simple statement like that would be suffice: BDF properties such as CHARSET_REGISTRY, RESOLUTION_X, (you can list all the favorite ones) etc can also appear in HBF file. They have exactly the same meaning as in BDF, please refer to [??] for more detail. Instead of taking several pages to describe them. > On the other hand, if none of BDF properties is mentioned in this > document, then the reader may not know what's BDF properties, and > he may not be interested to dig up any X documents (as he is not > an X programmer/user user anyway). They can just simply ignore them. > The HBF Standard v1.0 is long; however, if any redundancy does not hurt > the "completeness", then I prefer to keep the above (and some other > relevant parts). Didn't you try to reduce the length by not supporting HBF_ORIENTATION? :-)) Just kidding. > > > A utility program "tofhbf" (not "shbf2fhbf", which has more > > > than 8 letters and is not acceptable in MS-DOS) can convert > > > > Since HBF is a system independent spec, I think it's better not to > > mention system dependent obscurities. > > Ideally, no system dependent specific information should be in a standard. > > However, by defining the name of the utility program, > the same user using different systems doesn't have to learn probably > different sets of commands (e.g. tofhbf, 2fhbf, shbf2fhbf, shbftofhbf, > sHBF2fHBF {some systems have case sensitive commands}, etc.). > > Thus I prefer to mention the name explicitly in the document. I am not against having a less than 8 character name, but suggest taking out the comment on MS-DOS to make the document more system independent (which it should). BTW, since I doubt the need to have "simple" and "full" HBF, naturally I don't see the need for the utility tofhbf. :-) I think the desirable utilities should really go into another document. Please see my message on re-organizing this draft. > If more people think we should delete such things, > I'm ready to delete them. > > Now is one vote (me) for and one vote (Ricky) against :-) :-) > > > HBF_Octet /* an 8-bit byte */ > > > PtrHBF_Octet /* pointer to HBF_Octet sequence (a bitmap) */ > > > > > > [[ "PtrHBF_Octet" is more readable than "HBF_Octet *" ]] > > > > Personally I found the name Octet quite awkward. Why not call it byte? > > Or better yet, BITMAP, which is defined clearly in this HBF spec. > > > > typedef char *BITMAP; > > "Byte" or "byte" is such a commonly used identifier that it may be defined by > the application. > I use "HBF_Octet" only for the reason to avoid possible duplicated declarations. > Also Octet suggests it's an 8-bit thing -- it's a term from the network world. > > I can use "HBF_Byte"; note that it is different from "HBF_Bitmap". > > The former is a byte. > The latter is a pointer to a byte sequence which is more implementation > oriented. We can use HBF_Bitmap to hide this implementation fact; but > this fact must be known by the programmer. Thus I use PtrHBF_Octect. I think HBF_Bitmap is sufficient and it's only for readibility. Since the spec already dictates that a hanzi bitmap is a sequence of bytes (char); thus the implementation is fixed. > (I prefer Ptr... instead of ...Ptr -- this is personal taste. > My reason is that Ptr... is more readable: "Pointer to something".) I agree that's personal taste, but it seems better to be consistent if using the prefix convention (which is quite common in industry). > > > A sample implementation in Unix/C can be: > > > ... > > > char* HBF_GetProperty( > > > IN HBF_Handle handle, > > > IN char * propertyName ); > > > > I think you meant "should NOT free" here, otherwise the HBF library has > > to make a copy of the property value string on each inquiry. The > > returned property value should be treated as constant anyway. > > I really mean "should free". > I am thinking that the HBF_Handle internal structure **may** not store > the lines of properties exactly as specified in the HBF file. > Thus, HBF_GetProperty may have to construct back the string in the > returning format (like squeeze out extra blanks, remove leading & > trailing blanks). To avoid memory leakage, the application should > free it. > > As modern CPU runs fast enough, allocate an "extra" copy of string > doesn't cause much, & also, this function should not be called frequently. > (The application can forget to free it; actually won't waste much :-) > > If not, then the specification dictates(?) the implementation that > the property strings must be kept in ready-to-return form. The property values should be treated as constant anyway. If for C++, I would make this routine return a const char*. On the other hand, the proposed API dictates the implementation that it either needs to construct back the string every time it's called, or do it once and make a copy every time, i.e. you can't share the property value strings. Both free or not dictate the implementation somewhat. Treating property value string constant and promote sharing seem more compelling to me. (For example, for the C library call getenv, my C reference manual says: The value string should not be modified by the programmer, and it may be overwritten by a subsequent call to getenv. Which implies that you should not free the return value.) > > > * In Standard v1.0, only properties in simple HBF file are valid. > > > > Why put that restriction? > > This is for simple implementation which can claim conformance to > Standard v1.0. > If not, then it seems that it is necessary to support all X11R5 BDF > -- which seems to be not very appropriate for PC. > > Also, the full HBF properties are only really useful in X environment. > (Font server is an even further away business.) > I was thinking of a simple implementation that the routine just searches the property list read in from the HBF file and returns NULL if no such property found. Requiring this routine to check for conformance means that every time a new keyword is added, the library (or associated database) needs to be modified and each HBF_GetProperty call needs to string search through a long list. How about having a separate utility to check for conformance and not do that at application run-time? > > I think HBF_GetBitmap shouldn't return a bitmap upon invalid hanzi code, > > otherwise there is no way for the program to detect missing characters. > > On the other hand, if HBF_GetBitmap returns NULL on invalid code, the > > program can always get the DEFAULT_CHAR bitmap if it wants to. > > That's what I understand "DEFAULT_CHAR" supposed to mean. The following > is in HBF Standard v1.0 and is adopted from the X11R5 document (except > that the word "optional" before unsigned integer was omitted, as suggested > by F.F.Lee(?) ). > > (9) DEFAULT_CHAR defaultCharCode > > defaultCharCode: an unsigned integer specifying the hanzi code > to be used when an attempt is made to display an undefined or > ^^^^^^^^^ > non-existent glyph in the font. > ^^^^^^^^^^^^ > I regard that it means invalid hanzi code. Right, when the programmer gets a NULL bitmap from GetBitmap, it can then get the bitmap of defaultCharCode to display an undefined glyph. S/he may want to do something upon invalid code, such as printing a message, etc. If GetBitmap always returns a bitmap, you can't tell. > > > A2.2 Desirable Application Programmer Interface (API) routines > > > > > > ... > > > > > > PtrHBF_Octet HBF_GetBitmapRotated90( > > > IN HBF_Handle handle, > > > IN HBF_hzcode hanziCode ); > > > > > > /* Get the bitmap rotated for 90 degrees anticlockwise > > > * about the centre of the bitmap for the given hanzi code. > > > * RETURN the pointer to the bitmap of the hanzi; > > > * or the pointer to the bitmap of the DEFAULT_CHAR > > > * if invalid hanzi code; > > > * or NULL if invalid HBF handle. > > > * > > > * This routine may be implemented in assembly code for speed. > > > */ > > > /************************************************************/ > > > > Are these "desirable" routines enough? > > Maybe not enough, as suggested by the following examples. > > > How about routine to inverse the > > hanzi bitmap? How about mirroring a bitmap horizontally/vertically? > > Routines to scale and merge bitmaps (they can be used to create missing > > characters, for example, I can use the "no" character and the "big" > > character to form the Cantonese(?) character "tiny, not big" ("no" over > > "big"))? How about rotating a bitmap in any angle? > > These can be left for future HBF Standard vX.Y, if DEEMED NECESSARY. > See below why 2 of which, HBF_GetBitmapRotated90 & HBF_GetBitmapRotated270, > are deemed necessary. Please see my mail on reply to HBF_GetBitmapRotatedXXX(). > > Are they plus the ones in this section really desirable? I doubt. HBF > > should be simple and minimal. Generic routines to manipulate bitmaps > > like the above and the following are most likely provided by the OS > > (like Windows, X11, Mac's QuickDraw) or the language graphics library > > anyway. Why duplicate them in the HBF API? > > Actually at first I only try to mention > HBF_GetBitmapRotated90 & > HBF_GetBitmapRotated270 > > They are for allowing bitmaps for dot-matrix printers, and to provide > the API routines ready for packages like BYX 1.1 to use HBF fonts > instead of column-major bitmap font files. > > If we have these, then such packages should be easy to convert to use > HBF fonts. (No excuse to not changing? :-) :-) > > The reason for mentioning as an Appendix is to avoid proliferation of > different routine names for such functions, as mentioned at the start > of the Appendix: > > The API routines listed below are not required for an implementation > to be conformed to the HBF Standard v1.0. It is foresee that they > should be useful for some applications on some systems. To avoid > the proliferation of different routine names for such functions, > they are listed here, so that hopefully in future HBF Standard v2.0, > they will be supported using such routine names. > > ... > > > > PtrHBF_Octet HBF_GetBitmapRotated180( > > > IN HBF_Handle handle, > > > IN HBF_hzcode hanziCode ); > > > > > > /* Get the bitmap rotated for 180 degrees anticlockwise > > > * about the centre of the bitmap for the given hanzi code. > > > * RETURN the pointer to the bitmap of the hanzi; > > > * or the pointer to the bitmap of the DEFAULT_CHAR > > > * if invalid hanzi code; > > > * or NULL if invalid HBF handle. > > > > What's the result if the bitmap is not squared? Should it be truncated > > or scaled? Oops. I meant Rotated90 and Rotated270. If the bitmap is not squared, say M*N, you have three choices: return an M*N rotated bitmap but then you need to specify if the rotated bitmap is truncated or scaled. If it returns an N*M bitmap, you need to define what it means regarding to the boundingbox. > Rotated90 & Rotated270 should be there, then I think: > to be "complete" to a certain extent, why not mention Rotated180 as well :-) > > BTW, if the bitmap is rectangle, the returned bitmap (byte sequence) will be > a rotated rectangle about the centre of the original one. > > > > * This routine may be implemented in assembly code for speed. > > > */ > > > /************************************************************/ > > > > I don't think it's appropriate to instruct the implementor in that level > > of detail. Moreover, with the advance in compiler and hardware > > technology today, I really doubt that you need to code these routines in > > assembly for speed. > > It's just a reminder. I put this line in after reading one of the mail > suggesting that both Intel & Motorola chips have special instruction for > bitmap rotation. :-) > Some may be concerned about the speed of rotating bitmap vesus extra font > file space. Thus I add this line, hoping to convince that speed is > not a problem. :-) Please see my mail on rotation speed. -Ricky From Ricky.Yeung@Eng.Sun.COM Mon Mar 8 11:07:18 1993 Return-Path: Date: Mon, 8 Mar 93 01:35:51 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: soft-authors@ifcss.org In-Reply-To: Dr. PONG Man Chi's message of Mon, 8 Mar 93 15:05:43 HKT <9303080705.AA02629@uxmail.ust.hk> Subject: [Re: HBF_GetBitmapRotatedXXX()] & Document Organization Content-Length: 1770 Status: O > Nevertheless, I think keeping HBF_GetBitmapRotated90() > and HBF_GetBitmapRotated270() is appropriate -- they will not be > a requirement for conformance to HBF Standard v1.0; but only deemed > as desirable. Notice that BYX's ZIKU24 is rotated and relected(?). Thus Rotated90 alone is not enough if the routines' main purpose is to support BYX. Also, if for a size W*H font, HBF_GetBitmapRotated90 returns back an H*W size font, it needs to specify what's the relationship between it and the bounding box. Moreover, HBF_GetBitmapRotated90 is really an HBF_GetBitmap followed by HBF_BitmapRotate90. Such a factoring seems more appropriate. Personally, I am against to put in a couple calls like that in the API to hope to specifically satisfy one or two audience. I'm afraid that this opens the door for the proliferation of API's in the future: more generic bitmap routines would be added and the HBF library becomes something like a bitmap server, most likely duplicating the underlying graphics library (which I think would be the right layer to support the special need for software like BYX). ========================= I suggest we have three separate documents instead of the current draft format (which sort of putting 2 & 3 in the appendices): 1. HBF spec. Its sole purpose is to define the HBF file format. It will also provide pointers to optional documents 2 and 3 in the reference, but they are not part of the specification. 2. Recommended API and utilities (plus a sample implementation when ready). This document will probably be revised more often while a sample implementation is constructed. 3. An archive of the HBF e-mail exchanges. It's for those who want to trace the rationale of HBF. -Ricky From CAI@neurophys.wisc.edu Mon Mar 8 11:21:29 1993 Return-Path: Date: Mon, 8 Mar 93 11:19 CST From: CAI@neurophys.wisc.edu Subject: Re: rotation and reflection To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O Frist of all, I took back the last paragraph of my last posting and apologize to Mr. Simpson and all parties that may have been affected. .CAI@neurophys.wisc.edu writes: . > I vote against putting it in V1.0, but we can consider to add it in later . > versions. . > ... . > If we put it on, we have to check this proverty as well if we want to match . > a font. .I don't understand what is meant here by "matching a font". Under my .proposal, application software is free to ignore the rotation and .reflection properties of fonts, i.e. to assume rotate = reflect = 0. .That is up to the application software developer to decide. . ...... Here I meant the application has to decide whether to rotate/reflect the bitmap after a font is matched by other properties. I do not think an application software can simply ignore the rotate/reflect property because it may get a rotated/reflected bitmap. At this point I am still not convinced on either Simpson's suggestion or F. F. LEE's recent proposal, but as I said in the previous mail we can keep this issue open. Anyway, this is just one vote from me as both MC Pong and Mr. Simpson called for voting. I think the points in Pong's recent posting regarding rotation/reflection is well justified. Once again I am FOR the idea to postphone the rotation /reflection to v0.2 so that we can see if the reason behind this idea is really well justified. Ricky's recent experiment seems to be not in favor of the rotation and reflection (I understand it is not conclusive). Regards, Yidao Cai From lee@fritter.Stanford.EDU Mon Mar 8 16:06:40 1993 Return-Path: Date: Mon, 8 Mar 93 14:04:02 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Re: HBF v1.0 draft 0.2 Status: O Finally I have time to read over draft 0.2 more carefully. Following are some of my comments and suggestions. >Standard for the File Format of Hanzi Bitmap Font (HBF) Version 1.0 >------------------------------------------------------------------- Actually this document is the specification of the standard. Hence, following how references[1][2] are titled, I suggest the title: Hanzi Bitmap Font (HBF) File Format Specification Version 1.0 ------------------------------------------------------------- >(Compressed bitmap files will be considered in future versions.) ^^^^ may [[don't make a promise yet :-)]] >HBF_VERSION 1.0 > ... [deleted] >ENDFONT A better pair of keywords is perhaps HBF_START_FONT 1.0 HBF_END_FONT Isn't this more consistent with the naming convention, in line with HBF_START_CODE_RANGES, HBF_END_CODE_RANGES ? >(10) COPYRIGHT string > >string: a human-understandable quoted string that gives the copyright >information of the legal owner of the HBF file. > >E.g., COPYRIGHT "public domain simple HBF file (1993)" > There are really only a very limited number of ways to write a HBF file to include a given number of bitmap files. Is there any undesirable consequence if the copyright of some HBF files are not public domain? This is a non-technical issue we may worry about after we are done with the technical "meat". >(11) NOTICE string > >string: a human-understandable quoted string that gives the copyright >information of the legal owner of the font design of the bitmap file. > >E.g., NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." > Is this a BDF property? Do we intend to put only BDF properties inside the X11R5FontPropertySection? Just need a confirm. >(15) 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 hanzi codes. > >It is required that: > 0 <= rangeStart <= rangeEnd <= 0xFF > >The sub-ranges must be given in increasing order. >(This saves the need to sort the sub-ranges in implementation.) > >[[ F.F.Lee recommends the last point. For an implementation independent > specification, ideally one should not specify any details of > implementation. But this is a good idea, and so we can > enforce it by stating this explicitly in the Standard. >-- mcpong ]] > Well, let's put it this way. This "sorted" constraint is motivated by implementation considerations, but the constraint itself is implementation independent -- it's just part of the semantics. >unquotedString ::= char { char } . > >quotedString ::= '"' char { char } '"' . > >/* char can be any printable ASCII character except '"'. */ > >[[ I can't find in the XLFD or BDF documents ([1] and [2]) > saying whether \" is allowed to mean " or not. > Thus to play safe to ensure compatibility with BDF, > just ban the use of " in quotedString and unquotedString. >-- mcpong ]] > Agree. >unsignedInteger ::= digit { digit } . /* unsigned integer in C language */ > >/* unsignedInteger can be read in by C scanf functions using %i format */ > >[[ By not enforcing 16-bit integer, the implementation should use > variables of type "unsigned integer", not necessarily "short", > to store the value. >-- mcpong ]] > I made a suggestion referring to draft 0.1 to specify the integer size. It was based on the observation that all integer values mentioned in the spec (except file byte offset) fit in 16 bits for all practical purposes. In the ANSI C standard, int is guaranteed to have AT LEAST 16 bits, but it may also be only 16-bit long. You know how many things in C assume int by default. By enforcing unsignedInteger is no greater than 16 bit, we can safely use int; otherwise we have to use long because on some machine/compiler int is only 16 bit long. However, as suggested by M.C., don't use short. What I meant is: unsignedInteger16 ::= digit { digit } . /* unsigned integer in C language */ /* unsignedInteger16 can be read in by C scanf functions using %i format */ typedef unsigned int u_int16 typedef int int16 Keeping the name for unsignedInteger with implied maxiumum 16-bit size requirement is ok. [[The above paragraphs are the rationale, and not intended to be included in the spec.]] >unsignedInteger32 ::= digit { digit } . /* 32-bit unsigned integer */ > >/* unsignedInteger32 can be read in by C scanf functions using %l format */ -Fung From lee@fritter.Stanford.EDU Mon Mar 8 16:34:47 1993 Return-Path: Date: Mon, 8 Mar 93 14:32:36 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Ricky Yeung's message of Mon, 8 Mar 93 04:00:51 PST <9303081200.AA07695@hk.Eng.Sun.COM> Subject: Re: Ricky's comment on 0.2 Status: O >Date: Mon, 8 Mar 93 04:00:51 PST >From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) > > >Since there are simple and full HBF files, do you allow something >in-between, not-so-simple-but-not-really-full HBF file? :-)) > Agree. I accept the terms "simple HBF file" and "full HBF file" as a shorthand to talk about the two extremes. Some has no optional properites, some has more, some even has all. It is up to the application to decide what properties it should look at or ignore. Using Ricky's idea about HBF_GetProperties() to handle optional properties, any HBF file can be easily dealt with by a full-conformance HBF library. > ... [too long, deleted] I agree with the rest of Ricky's comments. Fung From ygz@cs.purdue.edu Mon Mar 8 16:59:35 1993 Return-Path: To: soft-authors@ifcss.org Subject: sideway font Date: Mon, 08 Mar 1993 17:57:00 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O Now we have some diverged opinions on whether to support sideway fonts or not. Simpson and yawei are strongly for it. Cai, mcpong, and yueng are against it. F.F.Lee is against it but willing to compromise. :-) Here I suggest we move the concept of sideway fonts from the language to the application program. That is, we do not provide HBF_ORIENTATION or any other constructs, which will enforce interpretations on the visual glyph. Instead, we specify that in ADD_STYLE_NAME or some other field. Therefore, the "sideway-style" font is just another font to HBF, _not_ the same font with different format. So, we can still handle sideway-style font in HBF v0.2. We can write .hbf for it as if it were upright. For example, a 15x16 font stored in sideway format is actually a 16x15 HBF font. I think BYX can use sideway fonts for printing this way, and one can use other sideway fonts this way too. If one cannot even afford the 10% overhead in runtime rotation (as pointed out by R.Yeung), he/she must have some reason, and we cannot do much about this. I am suggesting this trick for those who really depend on sideway fonts for the sake of performance, although I myself don't consider it a good practice. Note that the sideway-style font is for printing only. Of course if you insist putting the bitmap on screen it will look strange, very strange. But there will be a set of upright font for display anyway. Why? If the objective to use sideway font is to save time, to rotate sideway font back for display doesn't make any sense. Conclusion: 1. Normally a programmer should use upright HBF and do runtime rotation for printing. 2. If speed is so desirable, make a separated set of "sideway-style" HBF fonts and use those for printing only. The key point here is that HBF only facilitates the handling of the fonts. It cannot add semantics to the glyph. Although I believe this pratice (to use sideway-style font as if it were upright) will create non-standardized usage. But there is no way to stop it, no matter how restrict the HBF is. -ygz In message <9303080122.AA27285@uxmail.ust.hk> mcpong writes: > (Anyway, BYX has to convert between upright bitmap and sideway bitmap > in order to display and print, respectively.) Not necessary. It could keep both sets of fonts. > The allowance of non-upright hanzi bitmap font in HBF Standard v1.0 > may be mis-interpreted as that we don't want a future hanzi bitmap > font to be in 1 set of bitmap files only PER STYLE AND BITMAP SIZE. One can always say a sideway font is just another STYLE, with abnormal glyphs. > That is, the use/support of two formats of the "same" font (only > differ in format) should be discouraged. There is no way you can stop that. > By only supporting upright bitmap in the Standard v1.0, the programmers > have a chance to see if v1.0 really serves the purpose and their need. I believe so. They can also get around it using tricks like this one. :-) --ygz From lee@fritter.Stanford.EDU Mon Mar 8 17:09:19 1993 Return-Path: Date: Mon, 8 Mar 93 14:59:57 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: CAI@neurophys.wisc.edu's message of Mon, 8 Mar 93 11:19 CST <23030811190213@neurophys.wisc.edu> Subject: rotation and reflection Status: O >At this point I am still not convinced on either Simpson's suggestion or >F. F. LEE's recent proposal, but as I said in the previous mail we can keep >this issue open. Anyway, this is just one vote from me as both MC Pong and >Mr. Simpson called for voting. As said in my recent proposal, I offered my solution as a compromise. Sensing that the "consensus" has shifted since then, and knowing that there is a clean backward compatible way to add HBF_ORIENTATION later if desired, I favor supporting only "upright" bitmaps for now. Hopefully, there will be NO need to add HBF_ORIENTATION in the future. Are we ready to count the votes and settle on this issue? I also think it's about time to write down HBF files for all the bitmap files archived on, say, ifcss.org:software/fonts, if possible. Would authors such as Yawei and Yidao who are familiar with those CCDOS font files take the job, in addition to Simpson's ETen example and my example on "chinese.16" ? Fung From lee@fritter.Stanford.EDU Mon Mar 8 17:40:51 1993 Return-Path: Date: Mon, 8 Mar 93 15:38:52 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Yongguang Zhang's message of Mon, 08 Mar 1993 17:57:00 -0500 <199303082257.AA04920@ector.cs.purdue.edu> Subject: sideway font Status: O >Now we have some diverged opinions on whether to support sideway fonts >or not. Simpson and yawei are strongly for it. Cai, mcpong, and yueng >are against it. F.F.Lee is against it but willing to compromise. :-) >From ygz's recent suggestion, it seems that he is also against it but willing to compromise to some degree. :-)) Actually, I had thought about ygz's type of solution before I posted my last solution. Yes, if ONE application wants to use HBF in the way it wants, it can always do it by adding new properties or even looking for some sort of "special" COMMENT lines. You cannot prevent it, as explained by ygz. But ONLY that application understands it. If everyone understands this new convention, then this convention must be well-defined, and thus effectively you have another standard. >The key point here is that HBF only facilitates the handling of the >fonts. It cannot add semantics to the glyph. Although I believe >this pratice (to use sideway-style font as if it were upright) >will create non-standardized usage. But there is no way to stop it, >no matter how restrict the HBF is. It is the responsibility of the creator of a HBF file to tell the truth. This is no different from the case with BDF or any font file format. The practice should be discouraged. One could create a "sideway" BDF file disguised as a "upright" BDF file, and wrote his own set of routines to manipulate it. But clearly this is against the spirit. Fung From yawei@bronze.ucs.indiana.edu Mon Mar 8 17:43:56 1993 Return-Path: Date: Mon, 8 Mar 1993 18:41:49 -0500 From: ~{QG9p~} To: lee@fritter.stanford.edu, soft-authors@ifcss.org Subject: Re: rotation and reflection Status: O I agree with Yeung that the penalty for font rotation is less with computers with higher speeds nowadays. But I would still suggest HBF provide a field to describe the sideway fonts. As Yongguang say, we can always pretend that the font is upright and use HBF to describe it, but one would like to be able to find out from the HBF header that the font is not upright, if one cares. Without the extra attribute, that the existing sideway fonts cannot be utilized fully. Of course I can rotate them back to upright position and then distribute an upright copy with my programs, but I'd like to be able to share the same physical file (sideway) file with other applications. Anyway, my consideration is really for "backward compatibility". So if there's strong opposition I will not insist on it. (My previous diatribe about assembly language was really saying that there are some good instruments in assembly language that are not available on high level languages, such as the RCL/RCR instructions in 80x86 assembly language that are good for image rotation/reflection whatever.) I haven't read the draft very carefully so providing HBF descriptions will need to wait til later. Ya-Gui From CAI@neurophys.wisc.edu Tue Mar 9 09:40:19 1993 Return-Path: Date: Tue, 9 Mar 93 09:36 CST From: CAI@neurophys.wisc.edu Subject: sample HBF files To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O I am not familar with PC. The following are the simple HBF files for those fonts that I have actually tested before. I did not try to write full HBF files for them due to my limited knowledge, although I think a HBF file should contain all the properties defined in the full HBF format. These HBF files are supposed to conform with v0.2. 1. cclib.h24 ---------------------------------------------------------- simple HBF file for cclib.h24 on ifcss.org:/software/fonts. for cclib.j24, cclib.k24, cclib.f24 and cclib.n24, only the following lines need to be changed accordingly: FONT Jian24 FAMILY_NAME "song" ADD_STYLE_NAME "jianti" NOTICE "The raw bitmap file is that of the cclib.h24" HBF_CODE_RANGE 0xA1A1-0xA9FE "cclib.h24" 0 HBF_CODE_RANGE 0xB0A1-0xF7FE "cclib.h24" 60912 ---------------------------------------------------------- HBF_VERSION 1.0 HBF_CODE_SCHEME "GB2312-80" FONT Hei24 HBF_BITMAPBOUNDINGBOX 24 24 0 -2 FONTBOUNDINGBOX 24 24 0 -2 COMMENT Begin Logical Font Description -- 5 special properties for this FONT STARTPROPERTIES 5 FAMILY_NAME "hei" ADD_STYLE_NAME "jianti" DEFAULT_CHAR 0xA1A1 COPYRIGHT "public domain simple HBF file (1993)" NOTICE "The raw bitmap file is that of the cclib.h24" ENDPROPERTIES CHARS 7514 HBF_START_BYTE_2_RANGES 1 HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES COMMENT HBF_START_CODE_RANGES 2 HBF_CODE_RANGE 0xA1A1-0xA9FE "cclib.h24" 0 HBF_CODE_RANGE 0xB0A1-0xF7FE "cclib.h24" 60912 HBF_END_CODE_RANGES COMMENT COMMENT range 0xAAA1-0xAFFE is empty COMMENT ENDFONT 2. cclibh.24 ---------------------------------------------------------- simple HBF file for cclibh.24 on ifcss.org:/software/fonts. for cclibj.24 (cclib.24), cclibk.24, cclibf.24 and cclibb.24, only the following lines need to be changed accordingly: FONT Hei24 FAMILY_NAME "Hei" ADD_STYLE_NAME "jianti" NOTICE "The raw bitmap file is that of the cclibh.24" HBF_CODE_RANGE 0xA1A1-0xF7FE "cclibh.24" 0 ---------------------------------------------------------- HBF_VERSION 1.0 HBF_CODE_SCHEME "GB2312-80" FONT Hei24 HBF_BITMAPBOUNDINGBOX 24 24 0 -2 FONTBOUNDINGBOX 24 24 0 -2 COMMENT Begin Logical Font Description -- 5 special properties for this FONT STARTPROPERTIES 5 FAMILY_NAME "hei" ADD_STYLE_NAME "jianti" DEFAULT_CHAR 0xA1A1 COPYRIGHT "public domain simple HBF file (1993)" NOTICE "The raw bitmap file is that of the cclibh.24" ENDPROPERTIES CHARS 8178 HBF_START_BYTE_2_RANGES 1 HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES COMMENT HBF_START_CODE_RANGES 1 HBF_CODE_RANGE 0xA1A1-0xF7FE "cclibh.24" 0 HBF_END_CODE_RANGES COMMENT COMMENT note that cclibh.24 has exactly the same bitmap information as COMMENT cclib.h24 has. But since cclibh.24 encodes the range 0xAAA1-0xAFFE COMMENT (which is not defined), it takes 40K extra space. COMMENT with HBF, any HBF-supporting software that normally uses COMMENT cclibh.24 can use cclib.h24 without any change ENDFONT 3. cclib.16 ---------------------------------------------------------- simple HBF file for cclib.16 on ifcss.org:/software/fonts. for cclibf.16 the following lines need to be changed accordingly: FONT ?16 FAMILY_NAME "? " /* I DO NOT KNOW */ ADD_STYLE_NAME "jianti" NOTICE "The raw bitmap file is that of the cclib.16" HBF_CODE_RANGE 0xA1A1-0xA7FE "cclib.16" 0 HBF_CODE_RANGE 0xB0A1-0xF7FE "cclib.16" 21056 ---------------------------------------------------------- HBF_VERSION 1.0 HBF_CODE_SCHEME "GB2312-80" FONT ?16 HBF_BITMAPBOUNDINGBOX 16 16 0 -2 FONTBOUNDINGBOX 16 16 0 -2 COMMENT Begin Logical Font Description -- 5 special properties for this FONT STARTPROPERTIES 5 FAMILY_NAME "?" ADD_STYLE_NAME "jianti" DEFAULT_CHAR 0xA1A1 COPYRIGHT "public domain simple HBF file (1993)" NOTICE "The raw bitmap file is that of the cclib.16" ENDPROPERTIES CHARS 7426 HBF_START_BYTE_2_RANGES 1 HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES COMMENT HBF_START_CODE_RANGES 2 HBF_CODE_RANGE 0xA1A1-0xA7FE "cclib.16" 0 HBF_CODE_RANGE 0xB0A1-0xF7FE "cclib.16" 21056 HBF_END_CODE_RANGES COMMENT ENDFONT From lee@fritter.Stanford.EDU Wed Mar 10 12:53:34 1993 Return-Path: Date: Wed, 10 Mar 93 10:50:26 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Dr. PONG Man Chi's message of Fri, 5 Mar 93 18:46:28 HKT <9303051046.AA14295@uxmail.ust.hk> Subject: Ricky's comment on 0.2 Status: O >Date: Fri, 5 Mar 93 18:46:28 HKT >From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) > >> Date: Fri, 5 Mar 93 00:24:45 PST >> From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) >> > A2.1 Basic Application Programmer Interface (API) routines >> > >> > The implementation can define the following (abstract) data types: >> > >> > HBF_Handle /* a handle to access a HBF */ >> >> Since it's an abstract data type, maybe the name like HBF_FONT would be >> more appropriate. > >Either is fine for me. >HBF_FONT may be more "abstract" while HBF_Handle is more implementation >oriented. (though HBF means Hanzi Bitmap FONT already :-) >> > HBF_Struct /* a structure of information parsed from HBF file */ >> >> I don't think there is any user-accessible fields in this struct, and >> because HBF_FONT is an abstract data type, this shouldn't be exposed to >> the API. > >I agree. >Someone has proposed to have a struct (originally called "HBF_buff"??) >to hold all the information. >I'm not trying to dig up the mail record now to find out any rationale. > >I understand that HBF_Struct can provide provide faster access, >if one wants to do so; but of course, it's violating the >abstract data type (ADT) approach. > >(anyone still wants HBF_Struct?) > I'm the one who proposed the name "HBF_buff". The name was invented "on the fly" as a placeholder to point out that HBF_Handle (in draft 0.1) should not point to FILE. Only allowing HBF_FONT (a pointer to some struct) be visible is a better choice. >> > HBF_Octet /* an 8-bit byte */ >> > PtrHBF_Octet /* pointer to HBF_Octet sequence (a bitmap) */ >> > >> > [[ "PtrHBF_Octet" is more readable than "HBF_Octet *" ]] >> >> Personally I found the name Octet quite awkward. Why not call it byte? >> Or better yet, BITMAP, which is defined clearly in this HBF spec. >> >> typedef char *BITMAP; > >"Byte" or "byte" is such a commonly used identifier that it may be defined by >the application. >I use "HBF_Octet" only for the reason to avoid possible duplicated declarations. >Also Octet suggests it's an 8-bit thing -- it's a term from the network world. > >I can use "HBF_Byte"; note that it is different from "HBF_Bitmap". > >The former is a byte. >The latter is a pointer to a byte sequence which is more implementation >oriented. We can use HBF_Bitmap to hide this implementation fact; but >this fact must be known by the programmer. Thus I use PtrHBF_Octect. Can we simplify the matter by saying that HBF_GetBitMap() return (char *) ? char is a (8-bit) byte by definition. It seems to me that the fact that a bitmap is represented by a sequence of chars (in C's row major scheme) is exactly what should be exposed to the application programmer. >(I prefer Ptr... instead of ...Ptr -- this is personal taste. > My reason is that Ptr... is more readable: "Pointer to something".) > >> > HBF_HzCode /* a 16-bit hanzi code */ >> >> If hanzi code is an abstract type, then you better define API routines >> to access/retrieve the 1st and 2nd bytes, etc. A struct or unsigned >> integer impementation has quite different implications to the >> application programmers. I propose to define HBF_HzCode to be a minimum >> 16-bit unsigned integer. > >We can define more API: (may be functions or macros) > > HBF_Octet HBF_HzCodeByte1( HBF_HzCode hc ); > HBF_Octet HBF_HzCodeByte2( HBF_HzCode hc ); > ^^^^^^^^^ > or globally changed to HBF_Byte if the consensus is so. If HBF_HzCode (or HBF_Code for short, because we have only one kind of code) is a 16-bit hanzi code, then why not say that a hanzi code should be an unsigned integer with at least 16 bits? typedef unsigned int u_int16 or typedef unsigned int HBF_Code and explicitly saying that the more significant byte is byte 1, and the less significant byte is byte 2 ? It's just more natural and easier to write codes treating a hanzi code as an integer (for comparison, assignment, etc...) This saves us work in defining more ADT and more API. :-) Again, no matter which way we choose to settle, this is not properly part of the HBF file format specification. :-) Fung From mcpong@uxmail.ust.hk Tue Mar 9 21:35:39 1993 Return-Path: Date: Wed, 10 Mar 93 09:23:11 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: HBF v1.0 draft 0.2 Status: O > Date: Mon, 8 Mar 93 14:04:02 -0800 > From: lee@fritter.stanford.edu (Fung Fung Lee) > To: soft-authors@ifcss.org > Subject: Re: HBF v1.0 draft 0.2 > > >(11) NOTICE string > > > >string: a human-understandable quoted string that gives the copyright > >information of the legal owner of the font design of the bitmap file. > > > >E.g., NOTICE "The bitmap files are that of ETen system v2.00.03 or the equivalent." > > > Is this a BDF property? Do we intend to put only BDF properties > inside the X11R5FontPropertySection? Just need a confirm. NOTICE is a XLFD property; like COPYRIGHT. Basically XLFD properties are given within the STARTPROPERTIES ... ENDPROPERTIES section in a BDF file. The BDF properties which are not mentioned in XLFD document are: STARTFONT SIZE FONTBOUNDINGBOX CHARS ENDFONT ------ There are more people explicitly for NOT INCLUDING non-sideway bitmap in HBF v1.0. I shall try to modify draft 2 to incorporate the points raised recently. There may be splitting up of the document into different parts. I'm still not sure whether we should mention non-sideway bitmap at all, or if we should, how to mention it. The current intend is not to mention it at all. In the "rationale document", it will be mentioned that "the application has to take care of it". Please submit any further comments soon. Maybe over the weekend, draft 0.3 can be sent out. mcpong