From mcpong@uxmail.ust.hk Wed Feb 17 00:29:02 1993 Return-Path: Date: Wed, 17 Feb 93 13:59:40 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF Standard proposal v0.1 Status: O Proposed Standard for the File Format of Hanzi Bitmap Font (HBF) ---------------------------------------------------------------- (draft v0.1 -- first released for comment 1993/02/17) [[ mcpong -- Comment/rationale is enclosed in "[[" & "]]". ]] 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 those who have contributed actively to the discussion. Apology to those who have been missed from the list due to ignorance of the drafter of this document. (Update of the list is welcome.) CAI@neurophys.wisc.edu (CAI Yidao) lee@umunhum.stanford.edu (LEE Fung Fung) 87P0786@csdvax.csd.unsw.edu.au (NI Hongbo) mcpong@uxmail.ust.hk (PONG Man-Chi) xiaofei@ifcss.org (WANG XiaoFei) eric@coeus.ucsd.edu (YANG Bo) ryeung@hk.eng.sun.com (YEUNG Ricky) ygz@cs.purdue.edu (ZHANG Yongguang) All previous mail exchanges, related c programs, list of participants (soft.list), etc., are ftp'able from ifcss.org:/software/fonts/d/. 1. Introduction The aim of the standard is to allow different software to access some commonly available canonical representation of "hanzi bitmap font" (HBF) files. This is achieved by using a separate "HBF header file" to specify the properties of a HBF and the indices (or file offset information) to access the "raw bitmap files" of the HBF. 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 the ETen 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) format, based on the discussion in the mailing list soft-authors@ifcss.org till 1993/02/16. The format of HBF follows the X11R5 X Logical Font Description Conventions version 1.4 [1] and Bitmap Distribution Format (BDF) version 2.1 [2]. A "simple HBF" can ignore those properties irrelevant to fixed-width hanzi fonts. A "fully specified HBF" can have all the properties of a BDF file, so that it can be converted easily to an X11R5 font file. Software running in non-X window system can simply use the "simple HBF" format, and ignoring any complicated properties of the HBF. In section 2, some special terms used in this documents are defined. In section 3, the simple HBF is described, In section 4, the fully specified HBF is described. If the reader is not interested in X11R5 font properties, section 4 can be skipped. The appendix gives the formal syntax of the "simple HBF" format. This serves to check the compatibility of any implementation against this standard. The details of the "fully specified HBF" format can be found in references [1] and [2]. 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/XLFD/.) [2] Bitmap Distribution Format version 2.1, MIT X Consortium Standard, X11R5 (1991), by Adobe Systems, Inc. (available in X11R5 distribution mit/hardcopy/BDF/.) 2. Definition of terms Each hanzi is represented by a two-byte "hanzi code" in a computer system, no matter which encoding scheme is used. Common encoding schemes are: "GB2312-80", "ETen Big5 v2.x", "Unicode v1.x". 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 "header file" and "raw bitmap file(s)". A "header file" is an ASCII text file which describes: (1) the properties of the font, (2) index or file offset information (to the raw bitmap file(s)) of the different ranges of hanzi code. A "raw bitmap file" is a binary file of hanzi bitmaps indexed by the HBF header file. Without confusion, we can use the term "HBF file" to mean the "HBF header file" because it defines the essential information of a HBF. 2.1 "raw bitmap file" A "raw 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. That is, it is the bitmap of a hanzi in our current discussion.) 2.1.1 "uncompressed raw bitmap file" An "uncompressed raw bitmap file" stores the "full bitmaps" of each hanzi glyph. A full Row x Column bitmap is stored as a sequence of Row*((Column+7)/8) bytes, where integer division with truncation of decimal places is used in the calculation. E.g., a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes a 16x15 bitmap occupies 16*((15+7)/8) = 32 bytes a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes The bytes of the bitmaps follows each other consecutively. The most significant bit of the first byte is the upper-left bit of the glyph image; the least significant bit of the last byte is the lower-right bit of the image. (Note that the most or least significant bit of a byte is independent of whether the machine is a little or a big endian machine.) 2.1.2 "compressed raw bitmap file" For large glyph size, the uncompressed raw bitmap file is large. E.g., a 128x128 bitmap occupies 128*((128+7)/8) = 2048 bytes Some means will need to define a "compressed raw bitmap file". The START_BYTE_2_RANGES and the STARTSEGMENTS sections of a "header file" would need to be specially defined to access the data in a "compressed raw bitmap file". These are not yet defined in this version. [[ Don't know when it will be defined. The definition should allow for the use of more than one compression algorithms. Sample implementations can implement some of the easy-to-use compression algorithms. ]] 2.2 "(HBF) header file" A header file is an ASCII text file following the X11 BDF format, but with modification to tailor for the characteristics of hanzi. It contains the font name and other properties of the font, follows by index (offset) information to the raw bitmap file(s). [[ For the rationale of the indexing scheme in HBF in this standard and the comparison with other schemes, please see the summary made by F.F.Lee in ARTICLE 8 in his mail entitled "HBF (Hanzi Bitmap Format)" dated Sat, 30 Jan 93 19:57:31 -0800. ]] Each property of HBF is described by a line terminated with either the ASCII character newline or linefeed or (newline and linefeed). In each of the following sections, a sample HBF file is given and then the properties of HBF are described. Each property is introduced by a keyword spelt as a string of upper case letters. The property value is usually either a string or an integer-string. (An "integer-string" actually means a "number" in textual form. This term is used in reference [1].) A user-specified string is enclosed by a pair of double quotes '"'. The letters in a string are case insensitive, i.e. a lower case letter is equivalent to the corresponding upper case letter. An unsigned number can be given in either the decimal or hexadecimal format. A hexadecimal number is introduced by the prefix "0x". [[ mcpong -- octal format is not supported as it is not so readable. If there are strong requests, this document can be updated to include octal format. ]] 3. a simple header file The following is an example simple header file which uses the raw bitmap file supplied in the ETen system Version 2.00.03. HBFVERSION 1.0 ENCODING "ETen Big5 v2.0" FONT ETenKai24 FONTBOUNDINGBOX 16 16 0 -2 STARTPROPERTIES 3 DEFAULT_CHAR 0xA140 COPYRIGHT "public domain HBF file (1993)" NOTICE "The raw bitmap file is that of the ETen system." ENDPROPERTIES CHARS 13867 START_BYTE_2_RANGES 2 BYTE_2_RANGE 0x40-0x7E BYTE_2_RANGE 0xA1-0xFE END_BYTE_2_RANGES COMMENT STARTSEGMENTS 4 SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 SEGMENT 0xA440-0xC67E "STDFONT.24K" 24x24 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 24x24 0 SEGMENT 0xC940-0xF9FE "STDFONT.24K" 24x24 388872 COMMENT Smaller range for less-frequently-used hanzi COMMENT in standard Big5: 0xC940-0xF9D5 (7652 chars). COMMENT COMMENT Non-hanzi symbol (408 chars) bitmaps in "SPCFONT.24" COMMENT Vendor-specific symbols (365 chars) bitmaps in "SPCFSUPP.24K" COMMENT Frequently-used hanzi (5401 chars) followed by COMMENT less-frequently-used hanzi (7693 chars) bitmaps in "STDFONT.24K" ENDSEGMENTS ENDFONT The following explains the properties which are relevant to this HBF. (0) HBFVERSION formatVersion formatVersion: an unquoted string specifying which version of HBF format this file is conformed to, so that backback compatibility can be supported even if there is a change in the format definition. E.g. HBFVERSION 1.0 Note that the X11 keyword "STARTFONT" is not used to distinguish HBF from X11 BDF. (1) ENCODING stringOfEncodingScheme stringOfEncodingScheme: a string representing the encoding scheme, possibly with version number or publication date information. stringOfEncodingScheme is not an unquoted string because an exact match of this string is required if comparison is performed (e.g., to avoid the problem of with or without trailing spaces.) This is similar to the X11R5 X Logical Font Description (XLFD) property CHARSET_REGISTRY. With this extra ENCODING property, one can easily see what encoding scheme the HBF file supports. [[ We have to agree on what stringOfEncodingScheme are acceptable. A clearing house is also required to register the stringOfEncodingScheme. Here are some suggestions: ]] Common encoding schemes are: "GB2312-80" -- not simply "GB"; there are many GuoBiao's for hanzi. "ETen Big5 v2.0" -- not simply "Big5"; the no. of hanzi in a vendor-specific font may vary. "Unicode v1.x" -- not simply "Unicode"; everything alive is evolving and thus different versions exist. (2) FONT fontName fontName: either a simple case insensitive string with alphanumeric characters ('a'-'z', 'A'-'Z', '0'-'9') or a font name conforms to the X11 XLFD standard [1]. 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 (3) FONTBOUNDINGBOX width height xDisplacement yDisplacement width, height: of each bitmap. xDisplacement, yDisplacement: the displayment of the lower left corner of the bitmap from the origin. FONTBOUNDINGBOX values are the same for each glyph in the fixed pitch font. The values are in pixels of the device. A glyph is shown and aligned according to the FONTBOUNDINGBOX, which is illustrated here. |<--- width --->| - ----------------- - ^ | | | ^ | | | | | ascent | | | | | | | | height | | | | | baseline ---->- ----o------------ | Point "o" = origin | | | | | descent | | | | descent = yDisplacement v | | | v - ----------------- - |<--| xDisplacement The horizontal baseline of the glyph contains the origin. E.g. FONTBOUNDINGBOX 16 16 0 -2 instead of FONTBOUNDINGBOX 16 16 0 0 to align nicely with an ASCII font which contains letters with descents "-2", such as 'g', 'j', 'Q', etc. (4) STARTPROPERTIES p p: an optional unsigned number. It indicates the number of font properties that follows this line. (5) DEFAULT_CHAR defaultChar defaultChar: an optional unsigned number specifying the hanzi code to be used when an attempt is made to display an undefined or non-existent hanzi in the font. E.g., 0xa140 is the blank character in the ETen system fonts. DEFAULT_CHAR 0xa140 (6) COPYRIGHT string string: a human-understandable string that gives the copyright information of the legal owner of the HBF file. E.g., COPYRIGHT "public domain HBF file (1993)" (7) NOTICE string string: a human-understandable string that gives the copyright information of the legal owner of the font design of the raw bitmap file. E.g., NOTICE "The raw bitmap file is that of the ETen system." (8) ENDPROPERTIES This line indicates the end of the STARTPROPERTIES section. (9) CHARS totalNumberOfCharInFont totalNumberOfCharInFont: the total no. of the char in this HBF. E.g., CHARS 13867 There are 13867 characters in the raw bitmap files of the ETen system as illustrated in the examples in the STARTSEGMENTS section (see below). (10) START_BYTE_2_RANGES r r: optional unsigned number showing how many sub-ranges are validly represented by the byte 2 of the hanzi codes. [[ mcpong -- I used START_BYTE_2_RANGES instead of START_LOW_BYTE_RANGES to allow for future extension of 4-byte code in the ISO10646 encoding standard. Then START_BYTE_4_RANGES could be used. ]] E.g., there are two valid sub-ranges in the ETen Big5 code: START_BYTE_2_RANGES 2 (11) BYTE_2_RANGE rangeStart-rangeEnd rangeStart, rangeEnd: unsigned numbers showing the start and the end of a sub-range validly represented by the byte 2 of the hanzi codes. It is required that: 0 <= rangeStart <= rangeEnd <= 0xFF E.g., there are two valid sub-ranges of byte 2 for ETen Big5 code: BYTE_2_RANGE 0x40-0x7E BYTE_2_RANGE 0xA1-0xFE (12) END_BYTE_2_RANGES This line indicates the end of the START_BYTE_2_RANGES section. (13) COMMENT string string: an optional comment string. The COMMENT line can appear anywhere in the HBF file. (14) STARTSEGMENTS s s: an unsigned number showing how many continuous segments of hanzi code are valid in the whole coding space of the HBF. E.g., there are four valid segments in the ETen Big5 coding space: STARTSEGMENTS 4 (15) SEGMENT firstCode-lastCode rawBitmapFileName row x column offset firstCode, lastCode: unsigned number showing the first and the last hanzi code of a valid segment of the coding space of the HBF. For 2-byte hanzi code, it is required that: 0 <= firstCode <= lastCode <= 0xFFFF rawBitmapFileName: the name of the raw bitmap file containing the bitmaps for the segment. row, column: unsigned numbers. The bitmaps in the raw bitmap file are of size (row x column) bits. This is specified here to allow for different (non-square) bitmap size in different raw bitmap files referenced in different SEGMENTs. Bitmaps of different (row x column) values are aligned properly according to the FONTBOUNDINGBOX properties. It is required that: width of FONTBOUNDINGBOX >= maximum column value of SEGMENTs height of FONTBOUNDINGBOX >= maximum row value of SEGMENTs offset: an unsigned number showing the file offset of the bitmap of the hanzi code firstCode in the raw bitmap file. Other bitmaps of the hanzi code in the same SEGMENT follows in the raw bitmap file. E.g., there are four valid segments for ETen Big5 code: SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 SEGMENT 0xA440-0xC67E "STDFONT.24K" 24x24 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 24x24 0 SEGMENT 0xC940-0xF9FE "STDFONT.24K" 24x24 388872 COMMENT Smaller range for less-frequently-used hanzi COMMENT in standard Big5: 0xC940-0xF9D5 (7652 chars). COMMENT COMMENT Non-hanzi symbol (408 chars) bitmaps in "SPCFONT.24" COMMENT Vendor-specific symbols (365 chars) bitmaps in "SPCFSUPP.24K" COMMENT Frequently-used hanzi (5401 chars) followed by COMMENT less-frequently-used hanzi (7693 chars) bitmaps in "STDFONT.24K" (16) ENDSEGMENTS This line indicates the end of the STARTSEGMENTS section. (17) ENDFONT This line marks the end of the HBF header file. 4. a fully-specified header file The following is an example fully-specified header file which is equivalent to the simple header file described in section 3. HBFVERSION 1.0 ENCODING "ETen Big5 v2.0" FONT ETenKai24 COMMENT COMMENT An equivalent full X11R5 XLFD conforming font name is COMMENT -eten-kai-medium-r-normal-notspecial-24-240-80-80-c-240-eten.big5-0 COMMENT which are formed from the first 14 properties listed in COMMENT the STARTPROPERTIES section below. COMMENT Any of these properties is optional, as in the simple header file. COMMENT SIZE 24 75 75 FONTBOUNDINGBOX 24 24 0 -2 STARTPROPERTIES FOUNDRY "eten" FAMILY_NAME "kai" WEIGHT_NAME "medium" SLANT "r" SETWIDTH_NAME "normal" ADD_STYLE_NAME "notspecial" PIXEL_SIZE 24 POINT_SIZE 240 RESOLUTION_X 80 RESOLUTION_Y 80 SPACING "c" AVERAGE_WIDTH 240 CHARSET_REGISTRY "eten.big5" 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 header file. COMMENT DEFAULT_CHAR 0xA140 COPYRIGHT "public domain HBF file (1993)" NOTICE "The raw bitmap file is that of the ETen system." ENDPROPERTIES CHARS 13867 START_BYTE_2_RANGES 2 BYTE_2_RANGE 0x40-0x7E BYTE_2_RANGE 0xA1-0xFE END_BYTE_2_RANGES COMMENT STARTSEGMENTS 4 SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 SEGMENT 0xA440-0xC67E "STDFONT.24K" 24x24 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 24x24 0 SEGMENT 0xC940-0xF9FE "STDFONT.24K" 24x24 388872 COMMENT Smaller range for less-frequently-used hanzi COMMENT in standard Big5: 0xC940-0xF9D5 (7652 chars). COMMENT COMMENT Non-hanzi symbol (408 chars) bitmaps in "SPCFONT.24" COMMENT Vendor-specific symbols (365 chars) bitmaps in "SPCFSUPP.24K" COMMENT Frequently-used hanzi (5401 chars) followed by COMMENT less-frequently-used hanzi (7693 chars) bitmaps in "STDFONT.24K" ENDSEGMENTS ENDFONT Apart from the properties given for the simple HBF header 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: The point size of the character. In typography, 1 inch = 72.27 points. (Here let it be the no. of pixels on screen). 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) FOUNDARY foundryName foundaryName: 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 string that identifies the range or ``family'' of typeface designs that are all variations of one basic typographic style. (4) WEIGHT_NAME ( "medium" | "bold" | "demibold" | ... ) WEIGHT_NAME is a 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. In hanzi fonts, it seems that it is not so useful, because there is the special font "HeiTi" for "bold" hanzi. (5) SLANT ( "r" | "i" | "o" | "ri" | "ro" | "ot" ) "r": regular. "i": italic. "o": oblique. "ri": reverse italic. "ro": reverse oblique. "ot": other. SLANT is a code-string that indicates the overall posture of the typeface design used in the font. In hanzi fonts, it seems that it is not so useful, because there should be special italic font, if needed. (6) SETWIDTH_NAME ( "normal" | "condensed" | "narrow" | "double wide" ) SETWIDTH_NAME is a 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. (7) ADD_STYLE_NAME string ADD_STYLE_NAME is a 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 PIXEL_SIZE is 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 POINT_SIZE 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. POINT_SIZE 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 number (11) RESOLUTION_Y number RESOLUTION_X and RESOLUTION_Y are 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 ( "p" | "m" | "c" ) SPACING is a 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). "p": proportional. "m": monospaced. "c": charcell. (13) AVERAGE_WIDTH number AVERAGE_WIDTH is 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 string (15) CHARSET_ENCODING string 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 an x-registered-name that identifies the registration authority that owns the specified encoding. CHARSET_ENCODING is a registered-name that identifies the coded character set as defined by that registration authority. Usually, it is either CHARSET_ENCODING "0" or CHARSET_ENCODING "1" [[ FONTNAME_REGISTRY string -- obsolete in X11R5 ]] (16) FONT_DESCENT number (17) FONT_ASCENT number FONT_ASCENT is an integer value that gives the recommended typographic ascent above the baseline for determining interline spacing. FONT_DESCENT is an integer value that gives the recommended typographic descent below the baseline for determining interline spacing. Appendix 1: Formal Syntax of simple header file. The following uses the formal notation Extended Backus-Naur Form (EBNF) to describe a simple HBF header 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 ::= NewLineChar | CarrigeReturnChar | ( LinefeedChar CarrigeReturnChar ) . unquotedString ::= char { char } . string ::= '"' char { char } '"' . unsignedInteger ::= digit { digit } . HBFHeaderFile ::= 'HBFVERSION' formatVersion EOLN 'ENCODING' stringOfEncodingScheme EOLN 'FONT' fontName EOLN 'FONTBOUNDINGBOX' width height xDisplacement yDisplacement EOLN X11R5FontPropertySection 'CHARS' totalNumberOfCharInFont EOLN HBFByte2RangeSection HBFSegmentSection 'ENDFONT' EOLN . formatVersion ::= unquotedString . stringOfEncodingScheme ::= string . fontName ::= unquotedString . width ::= unsignedInteger . /* usually a decimal no. */ height ::= unsignedInteger . /* usually a decimal no. */ xDisplacement ::= unsignedInteger . /* usually a decimal no. */ yDisplacement ::= unsignedInteger . /* usually a decimal no. */ totalNumberOfCharInFont ::= unsignedInteger . /* usually a decimal no. */ X11R5FontPropertySection ::= 'STARTPROPERTIES' [ numberOfX11R5FontProperties ] EOLN X11R5FontProperty { X11R5FontProperty } 'ENDPROPERTIES' EOLN . numberOfX11R5FontProperties ::= unsignedInteger . /* usually a decimal no. */ X11R5FontProperty ::= 'DEFAULT_CHAR' defaultChar EOLN | 'COPYRIGHT' string EOLN | 'NOTICE' string EOLN . /* Only the X11R5FontProperty for simple header file is shown here. */ /* If the same X11R5FontProperty appears more than once, * the resulting value is that of the last occurrence. * An implementation may give a warning if deemed appropriate. */ defaultChar ::= unsignedInteger . /* usually a hexadecimal no. */ HBFByte2RangeSection ::= 'START_BYTE_2_RANGES' [ numberOfByte2Ranges ] EOLN HBFByte2Range { HBFByte2Range } 'END_BYTE_2_RANGES' EOLN . numberOfByte2Ranges ::= unsignedInteger . /* usually a decimal no. */ HBFByte2Range ::= 'BYTE_2_RANGE' rangeStart '-' rangeEnd EOLN . rangeStart ::= unsignedInteger . /* usually a hexadecimal no. */ rangeEnd ::= unsignedInteger . /* usually a hexadecimal no. */ HBFSegmentSection ::= 'STARTSEGMENTS' [ numberOfSegments ] EOLN HBFSegment { HBFSegment } 'ENDSEGMENTS' EOLN . numberOfSegments ::= unsignedInteger . /* usually a decimal no. */ HBFSegment ::= 'SEGMENT' firstCode '-' lastCode rawBitmapFileName row 'x' column offset EOLN . firstCode ::= unsignedInteger . /* usually a hexadecimal no. */ lastCode ::= unsignedInteger . /* usually a hexadecimal no. */ row ::= unsignedInteger . /* usually a decimal no. */ column ::= unsignedInteger . /* usually a decimal no. */ offset ::= unsignedInteger . /* usually a decimal no. */ rawBitmapFileName ::= string . Appendix 2: Implementation A2.1 Application Programmer Interface (API) routines The implementer can define the following (abstract) data types: HBF_Handle /* a handle to access a HBF */ HBF_Octet /* an 8-bit byte */ PtrHBF_Octet /* pointer to HBF_Octet sequence */ HBF_hzcode /* a 16-bit hanzi code */ A sample implementation in Unix/C can be: typedef FILE * HBF_Handle ; typedef unsigned char HBF_Octet ; typedef HBF_Octet * PtrHBF_Octet ; typedef unsigned short 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.) */ PtrHBF_Octet HBF_GetBitmap( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap for a given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * NULL if invalid hanzi code or invalid HBF handle. */ int HBF_GetFontBoundingBox( IN HBF_Handle handle, OUT unsigned int *width, OUT unsigned int *height, OUT unsigned int *xDisplacement, OUT unsigned int *xDisplacement ); /* Get the font bounding box information for a given HBF. * RETURN 0 if OK, and the font bounding box information * in OUT parameters. * 1 if invalid HBF handle. * * A hanzi code is required because a HBF may consist of * SEGMENTs which have different bitmap sizes, * though it is rare. */ int HBF_GetBitmapSize( IN HBF_Handle handle, IN HBF_hzcode hanziCode, OUT unsigned int *width, OUT unsigned int *height ); /* Get the bitmap size for a given hanzi code. * RETURN 0 if OK, and the width and height of the bitmap * of the hanzi in OUT parameters; * 1 if invalid hanzi code or invalid HBF handle. * * A hanzi code is required because a HBF may consist of * SEGMENTs which have different bitmap sizes, * though it is rare. */ other routines -- to be specified -- please suggest. A2.2 Desirable utility programs hbf2bdf < file.hbf > file.bdf -- converts a HBF header file and the associated raw bitmap files to an X11R5 BDF file. hz2ps -bdf file.bdf ... -- input a file of hanzi codes, use the file.bdf to output a postscript file of the hanzi. etc. /* please suggest */ ######### End of Standard for HBF ########## From CAI@neurophys.wisc.edu Wed Feb 17 10:58:15 1993 Return-Path: Date: Wed, 17 Feb 93 10:43 CST From: CAI@neurophys.wisc.edu Subject: Re: HBF Standard proposal v0.1 To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O .From: IN%"mcpong@uxmail.ust.hk" 17-FEB-1993 01:32:48.60 .To: soft-authors@ifcss.ORG .Subj: HBF Standard proposal v0.1 Thank you for your wonderful work, Mr. Pong. I am glad that finally we have a draft version. .This is achieved by using a separate "HBF header file" to .specify the properties of a HBF and the indices (or file .offset information) to access the "raw bitmap files" of the HBF. 1. Should this header be seperate or be part of the font file? .The details of the "fully specified HBF" format can be .found in references [1] and [2]. 2. Should it be DBF here ? .START_BYTE_2_RANGES 2 .BYTE_2_RANGE 0x40-0x7E .BYTE_2_RANGE 0xA1-0xFE .END_BYTE_2_RANGES .COMMENT .STARTSEGMENTS 4 .SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 .SEGMENT 0xA440-0xC67E "STDFONT.24K" 24x24 0 .SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 24x24 0 .SEGMENT 0xC940-0xF9FE "STDFONT.24K" 24x24 388872 3. How do I know which BYTE_2_RANGE to use for each segement? If this question was not due to my ignorance, I would suggest: a). If only one BYTE_2_RANGE, use this one for all segments. b). If more than one BYTE_2_RANGE, the number of BYTE_2_RANGEs should be the same as the number of segments. .FONT ETenKai24 4. Since a seperate bitmap font file is assumed in this standard, does this fontname refer to the actual name of the bitmap font file? If not, how do I find it? Regrads, Yidao From xiaofei Wed Feb 17 12:45:07 1993 Return-Path: Date: Wed, 17 Feb 93 12:40:43 CST From: xiaofei (XiaoFei Wang) To: soft-authors@ifcss.org Subject: more programs in /software/fonts/d Status: O With permission from authors, I have placed hz2ps-modified.c and cnprint-modified.c on ifcss.org:/software/fonts/d together with gb2ps-modified.c All these modified program use the same set of cclib fonts: cclibj.24, etc. This is for your reference only but not for public release. All these modifications were done by YLu of UK. I also modified some c programs written by YLu according to his instructions to make them compile on sun. I think there will be an endorsement list of people who agree with the standard and will use the standard in software development. This way people who do not use standard fonts will be left alone. I certainly will encourage uploaders to ifcss.org to use standard fonts. ( I have asked mcpong to remove my name from the contributor's list since I did not contribute anything technically. ) From mcpong@uxmail.ust.hk Wed Feb 17 21:08:46 1993 Return-Path: Date: Thu, 18 Feb 93 10:45:50 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: CAI's mail on Standard v0.1 Cc: mcpong@uxmail.ust.hk Status: O I'll send an update version of the HBF standard (v0.2) after some days, say, a week, when the first round of feedback comes back. > From CAI@neurophys.wisc.edu Thu Feb 18 00:50:21 1993 > > .This is achieved by using a separate "HBF header file" to > .specify the properties of a HBF and the indices (or file > .offset information) to access the "raw bitmap files" of the HBF. > > 1. Should this header be seperate or be part of the font file? I add a sentence to the end of this paragraph: The "raw bitmap files" are files existing independently of the "HBF header file". > .The details of the "fully specified HBF" format can be > .found in references [1] and [2]. > > 2. Should it be DBF here ? There are some errors during my editing of the draft v0.1, mainly due to redundant information. I intend to edit the last part of section 1 (Introduction) to become: The format of HBF essentially follows X11R5 X Logical Font Description (XLFD) Conventions version 1.4 [1] and Bitmap Distribution Format (BDF) version 2.1 [2]. A "simple HBF" can ignore those properties irrelevant to fixed-width hanzi fonts. A "fully specified HBF" can have all the properties of a BDF file, so that it can be converted easily to an X11R5 font file. Software running in non-X window system can simply use the "simple HBF" format, and ignore any complicated properties of the HBF. The details of the X11R5 font properties used in the "fully specified HBF" 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 is described, In section 4, the fully specified HBF 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" format. This serves to check the conformance of any implementation against this standard. For the sake of brevity (since some developers may not be interested in X11R5 BDF file format, the syntax of "fully specified HBF" is not described here and the details can be found in references [1] and [2]. Appendix 2 gives the intended application programmer interface routines and program utitlies to support and/or use this standard. The references are: [1] ... > > .START_BYTE_2_RANGES 2 > .BYTE_2_RANGE 0x40-0x7E > .BYTE_2_RANGE 0xA1-0xFE > .END_BYTE_2_RANGES > .COMMENT > .STARTSEGMENTS 4 > .SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 > .SEGMENT 0xA440-0xC67E "STDFONT.24K" 24x24 0 > .SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 24x24 0 > .SEGMENT 0xC940-0xF9FE "STDFONT.24K" 24x24 388872 > > 3. How do I know which BYTE_2_RANGE to use for each segement? > If this question was not due to my ignorance, I would suggest: > > a). If only one BYTE_2_RANGE, use this one for all segments. > b). If more than one BYTE_2_RANGE, the number of BYTE_2_RANGEs should > be the same as the number of segments. The BYTE_2_RANGEs depends on the ENCODING scheme. Common encoding schemes: BYTE_2_RANGE(s) "GB2312-80" 0xA1-0xFE "ETen Big5 v2.x" 0x40-0x7E 0xA1-0xFE "Unicode v1.x" 0x00-0xFF Now the standard requires that ENCODING is fixed in a HBF, the BYTE_2_RANGE(s) is/are the same (but not necessary **one**) for all SEGMENTs, no matter how many no. of segments there are. > .FONT ETenKai24 > > 4. Since a seperate bitmap font file is assumed in this standard, does this > fontname refer to the actual name of the bitmap font file? If not, how > do I find it? FONT ETenKai24 means that the HBF name is ETenKai24 (in MS-DOS, maybe ETKai24 is a more appropriate name (<= 8 chars)). It is not related to the "raw bitmap file(s)". The latter are specified in the STARTSEGMENT section. e.g. SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 ^^^^^^^^^^ means that the hanzi code in the SEGMENT 0xA140-0xA3BF, the bitmap can be found in the "raw bitmap file" "SPCFONT.24". The 24x24 bitmap of the hanzi code 0xA140 is at byte offset 0 of this file. Hope these can clarify. Thank you very much for the comment. ------------------------------------------------------------------------ Besides the above, I now suggest introducing 2 more fields "xDisplacement" & "yDisplacement" after the "row x column" fields in the SEGMENT line. Assume the syntax becomes: row 'x' column '+' xDisplacement '+' yDisplacement Suppose for a 16x16 HBF which uses the 15x16 raw bitmap files of ETen, FONTBOUNDINGBOX 16 16 0 -2 ... STARTSEGMENTS 4 SEGMENT 0xA140-0xA3BF "SPCFONT.15" 15x16+0+-1 0 SEGMENT 0xA440-0xC67E "STDFONT.15" 15x16+0+-1 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 15x16+0+-1 0 SEGMENT 0xC940-0xF9FE "STDFONT.15" 15x16+0+-1 162030 ^^^^^^ a make-up offset value for illustration only ENDSEGMENTS FONTBOUNDINGBOX is the property for the whole font. Here all 4 segments refer to the use of 15x16 bitmaps. Without the (xDisplacement, yDisplacement) information, there is a question of where to place the 15x16 bitmap within the 16x16 FONTBOUNDINGBOX. We assume that the origin of the 15x16 bitmap ALWAYS coincides with the origin of the FONTBOUNDINGBOX. Now with (xDisplacement, yDisplacement) = (0, -1), we shall have the following picture when showing the 15x16 bitmap: --- is the boundary of the FONTBOUNDINGBOX. ... is the bottom boundary of the 15x16 bitmap. |<--- width --->| = 16 ----------------- - |///////////////| ^ |///////////////| | |// 15x16 /////| | |// bitmap /////| height = 16 |///////////////| | baseline ----> o---------------- | Point "o" = origin (0,0) |///////////////| | -1|...............| | -1 = 15x16 bitmap yDisplacement a blank row--> | | v -2----------------- - -2 = FONTBOUNDINGBOX yDisplacement | ^ xDisplacement = 0 This is necessary, as I try to display a mix of CCLIB16 16x16 bitmaps and ETen 15x16 bitmaps. I find that add a blank row to the bottom of ETen 15x16 bitmaps make the two kinds of bitmaps look nicer than, say, adding a blank row to the top of ETen 15x16 bitmaps. The addition of the (xDisplacement, yDisplacement) makes such specification possible. Any comments? If it is agreed, this will be incorporated in draft v0.2. mcpong@uxmail.ust.hk From simpson@math.psu.edu Wed Feb 17 23:46:12 1993 Return-Path: From: Stephen G Simpson Date: Thu, 18 Feb 93 00:36:43 -0500 To: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) Cc: soft-authors@ifcss.org Subject: row x column should be column x row ? Status: O Dear Dr. Pong, Thank you very much for your draft of the HBF standard. I have one question. >From your 0.1 draft: > (3) FONTBOUNDINGBOX width height xDisplacement yDisplacement > ... > (15) SEGMENT firstCode-lastCode rawBitmapFileName row x column offset > ... > It is required that: > width of FONTBOUNDINGBOX >= maximum column value of SEGMENTs > height of FONTBOUNDINGBOX >= maximum row value of SEGMENTs It seems to me that `row x column' in (15) is in the wrong order. It should be `column x row', don't you think so? This would correspond better to (3) where you have `width height' rather than `height width'. This is because width is related to `column' values while height is related to `row' values, not the other way around. I think rectangular bitmaps are normally described in terms of width x height, not the other way around. For example, in the ET documentation, the 16 x 15 bitmaps are described that way (i.e. the width is 16 and the height is 15) rather than 15 x 16. I followed this convention in my posting to soft-authors@ifcss.org detailing the ET bitmaps. In your recent posting you have > row 'x' column '+' xDisplacement '+' yDisplacement > > SEGMENT 0xA140-0xA3BF "SPCFONT.15" 15x16+0+-1 0 > SEGMENT 0xA440-0xC67E "STDFONT.15" 15x16+0+-1 0 > SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 15x16+0+-1 0 > SEGMENT 0xC940-0xF9FE "STDFONT.15" 15x16+0+-1 162030 but what I am proposing is that it would be less confusing to change the specification so that you would say 16x15, i.e. column x row. Or, even better, leave `row x column' as it is, but change the definitions so that `row' would mean `size of a row', i.e. something like the width of the bitmap, and `column' would mean `size of a column', i.e. something like the height of the bitmap. I take it that you are currently using `column' to mean `number of columns' (something like `width') rather than `size of a column' (something like `height'), is that right? Under my alternative proposal, the precise relationship would be width >= maximum row value, height >= maximum column value. This would still mean 16x15 for the ET fonts. I admit that my contributions to this discussion are somewhat silly, but don't you think I belong on the list of `active' contributors? :-) Best wishes, Stephen G. Simpson From mcpong@uxmail.ust.hk Thu Feb 18 02:19:03 1993 Return-Path: Date: Thu, 18 Feb 93 16:08:10 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: simpson@math.psu.edu Subject: Re: row x column should be column x row ? Cc: soft-authors@ifcss.org Status: O > From simpson@math.psu.edu Thu Feb 18 13:39:31 1993 > > ... > > > row 'x' column '+' xDisplacement '+' yDisplacement > > > > SEGMENT 0xA140-0xA3BF "SPCFONT.15" 15x16+0+-1 0 > > SEGMENT 0xA440-0xC67E "STDFONT.15" 15x16+0+-1 0 > > SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 15x16+0+-1 0 > > SEGMENT 0xC940-0xF9FE "STDFONT.15" 15x16+0+-1 162030 > > but what I am proposing is that it would be less confusing to change > the specification so that you would say 16x15, i.e. column x row. I haven't thought carefully in this aspect when I composed the last mail. Thank you for comments; and that in the SEGMENT line, it's better to use width 'x' height '+' xDisplacement '+' yDisplacement or width height xDisplacement yDisplacement Actually, the latter is consistent with the X11R5 BDF conventions. So, if it's acceptable to others, then: SEGMENT 0xA140-0xA3BF "SPCFONT.15" 16 15 0 -1 0 SEGMENT 0xA440-0xC67E "STDFONT.15" 16 15 0 -1 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 16 15 0 -1 0 SEGMENT 0xC940-0xF9FE "STDFONT.15" 16 15 0 -1 162030 > ... don't you think I belong on the list of `active' contributors? > :-) Sorry for forgetting to put your name in. This will appear in next draft. mcpong :-) From CAI@neurophys.wisc.edu Thu Feb 18 10:42:45 1993 Return-Path: Date: Thu, 18 Feb 93 10:29 CST From: CAI@neurophys.wisc.edu Subject: comments (HBF) To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O .From: IN%"mcpong@uxmail.ust.hk" 17-FEB-1993 20:58:18.25 .Subj: CAI's mail on Standard v0.1 I have three more comments: .> 3. How do I know which BYTE_2_RANGE to use for each segement? .> If this question was not due to my ignorance, I would suggest: .> .> a). If only one BYTE_2_RANGE, use this one for all segments. .> b). If more than one BYTE_2_RANGE, the number of BYTE_2_RANGEs should .> be the same as the number of segments. .The BYTE_2_RANGEs depends on the ENCODING scheme. .Common encoding schemes: BYTE_2_RANGE(s) . "GB2312-80" 0xA1-0xFE . "ETen Big5 v2.x" 0x40-0x7E 0xA1-0xFE . "Unicode v1.x" 0x00-0xFF .Now the standard requires that ENCODING is fixed in a HBF, .the BYTE_2_RANGE(s) is/are the same (but not necessary **one**) .for all SEGMENTs, no matter how many no. of segments there are. 1. Since the standard requres that ENCODING is fixed in a HBF, and the BYTE_2_RANGE(s) in a standard is/are fixed, there is no need to check the BYTE_2_RANGE(s) for an application program, and an application program has to decide which BYTE_2_RANGE to use for a particular segment. In my suggestion, the application programs do not need to know (but it would certainly be better to know) which ENCODING is used and what format the source is (GB or BIG5), provided the user picked the correct font, because all the information about BYTE_2_RANGE and segments are provided by HBF file. . SEGMENT 0xA140-0xA3BF "SPCFONT.24" 24x24 0 . ^^^^^^^^^^ .means that the hanzi code in the SEGMENT 0xA140-0xA3BF, the bitmap .can be found in the "raw bitmap file" "SPCFONT.24". The 24x24 bitmap .of the hanzi code 0xA140 is at byte offset 0 of this file. ... .So, if it's acceptable to others, then: . SEGMENT 0xA140-0xA3BF "SPCFONT.15" 16 15 0 -1 0 . SEGMENT 0xA440-0xC67E "STDFONT.15" 16 15 0 -1 0 . SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 16 15 0 -1 0 . SEGMENT 0xC940-0xF9FE "STDFONT.15" 16 15 0 -1 162030 Yes, it is better than 16x15+0+-1 2. What exactly does this offset mean? I thank it refers to the ACTUAL address of the first element in the segment, for example, 162030 means the bitmap image of 0xC940 is stored in the file begining at 162030. Another interpretation might be the offset used to compute the address in the bitmap file. I think either way is OK, but we need to make it clear. 3. I think it would be easier for an application program if all bitmap information for a particular encoding (say, GB) is contained in one file. It would always be easier to deal with one file than dealing with more than one file. Maybe this is just a silly question in real world. Regards, Yidao From simpson@math.psu.edu Thu Feb 18 12:32:50 1993 Return-Path: From: Stephen G Simpson Date: Thu, 18 Feb 93 13:26:54 -0500 To: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) Cc: soft-authors@ifcss.org Subject: width, height, row, column Status: O Dear Dr. Pong, You wrote: > Thank you for comments; and that in the SEGMENT line, it's better to use > > width 'x' height '+' xDisplacement '+' yDisplacement > or > width height xDisplacement yDisplacement > > Actually, the latter is consistent with the X11R5 BDF conventions. > So, if it's acceptable to others, then: > > SEGMENT 0xA140-0xA3BF "SPCFONT.15" 16 15 0 -1 0 > SEGMENT 0xA440-0xC67E "STDFONT.15" 16 15 0 -1 0 > SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 16 15 0 -1 0 > SEGMENT 0xC940-0xF9FE "STDFONT.15" 16 15 0 -1 162030 This is to be used with a bounding box statement such as > FONTBOUNDINGBOX 16 16 0 -2 the template for which is > (3) FONTBOUNDINGBOX width height xDisplacement yDisplacement All of this seems fine, but I have a couple of suggestions. First, the `width' and `height' and `xDisplacement' and `yDisplacement' parameters in the SEGMENT statements are not the same as the same-named parameters (`width' etc) in the FONTBOUNDINGBOX statement. This seems confusing. Wouldn't it be better to use different names for different parameters? How about `bitmapwidth' etc for the parameters in the SEGMENT statement (since they are the actual dimensions and displacements of the raw bitmaps), and `bboxwidth' etc for the parameters in the FONTBOUNDINGBOX statment? Second, a more substantive point. In the HBF 0.1 draft standard, you have > FONTBOUNDINGBOX values are the same for each glyph in the > fixed pitch font. but > This is specified here to allow for different (non-square) bitmap > size in different raw bitmap files referenced in different SEGMENTs. My question is, why allow different bitmap sizes in different segments? In all of the bitmap fonts known to me, all the files or segments contain the same size bitmaps. To allow different bitmap sizes in different segments seems like going too far in the direction of flexibility (or maybe not far enough, because you don't allow different bounding boxes for different segments!). After all, one of the main reasons originally advanced for the desirability of HBF is to take advantage of the fact that all of the bitmaps in a Hanzi bitmap font are of the same size. So, it would seem more logical to have just one statement in the HBF file indicating the raw bitmap size, e.g. something like HBSIZE bitmapwidth bitmapheight which in the above example would be HBSIZE 16 15 My main suggestion is to make this information uniform over all segments. The question then arises as to where to present the information telling how to place the raw bitmap in the bounding box (i.e. the information that you are now calling `xDisplacement' and `yDisplacement' in each SEGMENT, and that I just proposed to call `bitmapxDisplacement' and `bitmapyDisplacement'). I see two possibilities here. We could present the information as additional parameters in the HBSIZE statement, or we could present it as additional parameters in the FONTBOUNDINGBOX statement. Both choices would be logical, but perhaps the first choice is better, because FOUNTBOUNDINGBOX is supposed to be compatible with BDF and adding extra parameters would destroy this compatibility. So, my proposal would be for something like HBSIZE bitmapwidth bitmapheight bitmapxDisplacement bitmapyDisplacment which in the above example would be HBSIZE 16 15 0 -1 or maybe the keyword HBSIZE should be changed to something more descriptive -- how about HBINFO? In any case, the SEGMENT statements would now be reduced to SEGMENT firstCode-lastCode rawBitmapFileName offset which in your example above would be SEGMENT 0xA140-0xA3BF "SPCFONT.15" 0 SEGMENT 0xA440-0xC67E "STDFONT.15" 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 0 SEGMENT 0xC940-0xF9FE "STDFONT.15" 162030 Does this makes sense to you? Again I want to thank you for drafting the HBF standard. I'm sure this is a tremendous amount of work, and you are doing an excellent job (as to be expected given your excellent qualifications as a developer of Chinese software). Stephen G. Simpson From lee@fritter.Stanford.EDU Thu Feb 18 13:26:23 1993 Return-Path: Date: Thu, 18 Feb 93 11:17:33 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Why HBF ? (Was Re: more programs in /software/fonts/d) Status: O After seeing Y. Lu's modification of hz2ps and other programs to demonstrate how all those programs can use CCLIB, I feel that there is a need to re-iterate the motivation behind HBF. (It is not clear from "hz2ps-modified.c" that which BIG5 font file will work for it.) I think for GB-only programs, standardizing on CCLIB font file format is perhaps not a bad idea, since most available PD font is either in CCLIB or its derivative. However, there are some problems. I am trying to convince you that HBF is a better idea. 1. CCLIB format is clearly not sufficient for BIG5 users. 2. If CCLIB format is chosen for GB, then something else has to be chosen for BIG5. 3. According to my understanding, CCLIB is not an open standard like BDF. Neither is any other popular format such as ETEN's. (Is there an official document of CCLIB format, of ETEN format?) (I don't know how stable or backward compatible vendor's formats are. For example, Macintosh Chinese OS (Taiwan version) changed the font formats when it switched from 1.x to 6.x, then changed again from 6.x to 7.x. The Mainland version even changed the internal code from Shift-GB to CCDOS-like (high-bit-set) GB from 1.x to 6.x.) 4. Rather than picking two vendor specific formats, why don't we create an open standard which is better and is designed for easy extension with backward compatibility (such as using BYTE_2_RANGE instead of LOW_BYTE_RANGE). 5. With an open well-specified single format (HBF), application programs can be relieved from the burden of dealing with various font file formats directly. With a standard API or library call interface, application programs can even be relieved the burden of writing their own font handling routines (Less re-inventing the wheel!). 6. This is possible because there is so much common properties among GB, BIG5, JIS, Unicode Han Character portion; the really encoding specific information can be captured by BYTE_2_RANGE and SEGMENTS firstcode-lastcode attributes of HBF. 7. For PC users who are interested in minimizing disk space usage and who happens to use CCDOS (ETEN) or some other Chinese operating system with its own required font files, HBF's "file pointers" (one per SEGMENT entry) relieves the need to duplicate the huge bitmap files at the cost of only one small HBF file. 8. If for some reasons, some bitmap files are missing, say less-frequently used hanzi of kai48x48, or user-defined font files are to be added, users can easily adjust by editing the HBF files without changing the application programs. 9. CCDOS has severe limitations on file name length (<= 8 chars + 3 chars of extension), but CCDOS and ETEN still try to squeeze the font attributes such as width, height, font-family, foundry-name in those file names, and hence making font naming convention a big deal. I think we should leave the file names alone and not to change them, to avoid confusion and possible copyright issues. We can afford this in HBF because HBF does not really care about those conventions. Yes, there is still an issue of naming the HBF header files. But this is really a side issue, just as the naming of BDF files are. 10. In terms of font structures, there is really very little difference between GB, BIG5 systems. (Unicode is not taking over the world tomorrow!) Who knows, perhaps the emergence of HBF acutally provides a better common platform for the GB and BIG5 worlds, and encourage more software both sides, as the HBF format and library will hide many differences. In summary, HBF is indeed a better idea. So let get some specification which leads to simple and efficient implementation. Fung F. Lee From lee@fritter.Stanford.EDU Thu Feb 18 15:18:41 1993 Return-Path: Date: Thu, 18 Feb 93 13:13:30 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Re: comments (HBF) Status: O First, I wish to thank M.C. Pong for his excellent work in writing HBF Draft 0.1. >Date: Thu, 18 Feb 93 10:29 CST >From: CAI@neurophys.wisc.edu > > 1. Since the standard requres that ENCODING is fixed in a HBF, and > the BYTE_2_RANGE(s) in a standard is/are fixed, there is no need to > check the BYTE_2_RANGE(s) for an application program, and an application > program has to decide which BYTE_2_RANGE to use for a particular > segment. > > In my suggestion, the application programs do not need to know (but it > would certainly be better to know) which ENCODING is used and what > format the source is (GB or BIG5), provided the user picked the correct > font, because all the information about BYTE_2_RANGE and segments are > provided by HBF file. > This was how I thought when I sent out the 5 sample HBF header files before Draft 0.1. After private communication with Ricky Yeung, I have now a second thought. First, we definitely still want to keep BYTE_2_RANGE. Second, ENCODING as defined in draft 0.1 is not totally redundant, because "ETen Big5 v2.x" contains more information than what one can infer from BYTE_2_RANGE. An inference is still an inference, we can still not be 100% sure that the encoding is really GB or BIG5, or yet something newly invented. I know it is perhaps not useful for many programs. However, Ricky proposed to use ENCODING for a more powerful font server. The server can look into the directory and picks the fonts with the right encoding. In this case, it is a must to know the ENCODING, but it is more important to match "Big5" than "ETen v2.x". Actually there could be minor variation among the various GB versions of DOS. Hence, to facilitate this possible usage, let's give (1) an ordering to the words within the quoted string, or (2) to eliminate vendor specific information, or (3) create another keyword: It seems (1) is the simplest. Common encoding schemes are (?): "GB2312-80", "Big5 ETen v2.x", "Unicode v1.x". "GB2312-80 CCDOS v?.x" [[ just made it up ]] > .So, if it's acceptable to others, then: > > . SEGMENT 0xA140-0xA3BF "SPCFONT.15" 16 15 0 -1 0 > . SEGMENT 0xA440-0xC67E "STDFONT.15" 16 15 0 -1 0 > . SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 16 15 0 -1 0 > . SEGMENT 0xC940-0xF9FE "STDFONT.15" 16 15 0 -1 162030 > > Yes, it is better than 16x15+0+-1 Stephen Simpson also pointed out whether it is worthwhile to over-complicate (or enhance :-)) the standard by allowing different bitmap sizes in different segments. The example given by M. C. Pong about mixing CCLIB.16 (GB ordeing) and ETen 15x16 (BIG5 ordering) seems not too convincing. I'm not sure which ways I should vote yet. More examples are welcome. I think this is perhaps to far the really BIG issue. Since this is controvesial, I would like to make the following proposal: change the ordering of the attributes in SEGMENT so that it becomes SEGMENT firstcode-lastcode bmfile offset width height xdisp ydisp e.g. SEGMENT 0xA140-0xA3BF "SPCFONT.15" 0 16 15 0 -1 SEGMENT 0xA440-0xC67E "STDFONT.15" 0 16 15 0 -1 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 0 16 15 0 -1 SEGMENT 0xC940-0xF9FE "STDFONT.15" 162030 16 15 0 -1 > 2. What exactly does this offset mean? I thank it refers to the ACTUAL > address of the first element in the segment, for example, 162030 means the > bitmap image of 0xC940 is stored in the file begining at 162030. Another > interpretation might be the offset used to compute the address in the > bitmap file. I think either way is OK, but we need to make it clear. > "offset" refers to the byte offset of the bitmapfile. The first byte of a file is at offset 0. > 3. I think it would be easier for an application program if all bitmap > information for a particular encoding (say, GB) is contained in one file. > It would always be easier to deal with one file than dealing with more than > one file. Maybe this is just a silly question in real world. > > Regards, > > Yidao With a standard API and associated library application programs do not really have to care about how it is implemented. See Appendix 2 of Draft 0.1. There are many practical advantages of not having separate header files and bitmap files, such as saving disk spaces, avoiding possible copyright infringement, providing flexibility for user-defined fonts, etc. Please see my article titled "Why HBF?" posted today. Fung F. Lee From CAI@neurophys.wisc.edu Thu Feb 18 16:08:07 1993 Return-Path: Date: Thu, 18 Feb 93 15:53 CST From: CAI@neurophys.wisc.edu Subject: Mr. LEE's comment (HBF) To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O .From: IN%"lee@fritter.stanford.EDU" 18-FEB-1993 15:09:47.20 .Subj: Re: comments (HBF) .> 1. Since the standard requres that ENCODING is fixed in a HBF, and .> the BYTE_2_RANGE(s) in a standard is/are fixed, there is no need to .> check the BYTE_2_RANGE(s) for an application program, and an application .> program has to decide which BYTE_2_RANGE to use for a particular .> segment. .> .> In my suggestion, the application programs do not need to know (but it .> would certainly be better to know) which ENCODING is used and what .> format the source is (GB or BIG5), provided the user picked the correct .> font, because all the information about BYTE_2_RANGE and segments are .> provided by HBF file. .> .This was how I thought when I sent out the 5 sample HBF header files before .Draft 0.1. After private communication with Ricky Yeung, I have now a .second thought. .First, we definitely still want to keep BYTE_2_RANGE. I think you misunderstood my point here. My original suggestion was: a). If only one BYTE_2_RANGE, use this one for all segments. b). If more than one BYTE_2_RANGE, the number of BYTE_2_RANGEs should be the same as the number of segments. And I should add c) to make it more clear: c). Each BYTE_2_RANGE matches the corresponding segment if b). I did not say we should eliminate BYTE_2_RANGE, but simply said if we did not specify which BYTE_2_RANGE to use for each segment, then the application program had to decide which BYTE_2_RANGE to use according to the ENCODING. Thus an application program could not handle an ENCODING scheme which comes out after the application program was written, because it would have problem deciding what BYTE_2_RANGE to use for each segment. Adding a few more lines of BYTE_2_RANGEs could avoid this problem. Yidao Cai From lee@fritter.Stanford.EDU Thu Feb 18 16:57:09 1993 Return-Path: Date: Thu, 18 Feb 93 14:49:42 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Re: HBF Standard proposal v0.1 Status: O >Date: Wed, 17 Feb 93 13:59:40 HKT >From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) > >Proposed Standard for the File Format of Hanzi Bitmap Font (HBF) >---------------------------------------------------------------- > >(draft v0.1 -- first released for comment 1993/02/17) >2.1.2 "compressed raw bitmap file" > >For large glyph size, the uncompressed raw bitmap file is large. > >E.g., > a 128x128 bitmap occupies 128*((128+7)/8) = 2048 bytes > >Some means will need to define a "compressed raw bitmap file". > >The START_BYTE_2_RANGES and the STARTSEGMENTS sections of a >"header file" would need to be specially defined to access >the data in a "compressed raw bitmap file". >These are not yet defined in this version. > >[[ Don't know when it will be defined. The definition should >>allow for the use of more than one compression algorithms. >>Sample implementations can implement some of the easy-to-use >>compression algorithms. >]] Everything can be the same with the understanding that all are referred to the uncompressed bitmap files, if we add a KEYWORD introducing the compressor/uncompressor that should be used. A HBF server should call other programs to do compression/decompression. I think we should defer this issue for future HBF version, and remove section 2.1.2. >Each property of HBF is described by a line terminated with either >the ASCII character newline or linefeed or (newline and linefeed). Should we intentionally make the EOLN token operating system dependent, just as that of normal text files and C source files are? This is an argument from the implementation side. Yes, the proposal can be implemented, but can be simplified? >An unsigned number can be given in either the decimal or hexadecimal >format. A hexadecimal number is introduced by the prefix "0x". >[[ mcpong -- octal format is not supported as it is not so readable. > If there are strong requests, this document can be > updated to include octal format. >]] A signed or unsigned number can be specified in the same way as ANSI C's sscanf %i conversion recognizes it. (Yes, ANSI C is a well-established standard) i.e. 0x or 0X for hex, leading 0 means octal, otherwise decimal, etc. Since it's free to support octal, why not? >(4) STARTPROPERTIES p > >p: an optional unsigned number. make p compulsory >(5) DEFAULT_CHAR defaultChar > >defaultChar: an optional unsigned number specifying the hanzi code >to be used when an attempt is made to display an undefined or >non-existent hanzi in the font. make DEFAULT_CHAR compulsory In the worst case when the application program has absolutely no idea what encoding it is dealing with, there is still something default. Of course, the application can choose its own default_char. >(9) CHARS totalNumberOfCharInFont ^^^^ Chars >(10) START_BYTE_2_RANGES r > >r: optional unsigned number showing how many sub-ranges are >validly represented by the byte 2 of the hanzi codes. > make r compulsory simplify implementation (one pass, one malloc(), no linked list, etc.) >[[ mcpong -- I used START_BYTE_2_RANGES instead of > START_LOW_BYTE_RANGES to allow for > future extension of 4-byte code in > the ISO10646 encoding standard. > Then START_BYTE_4_RANGES could be used. >]] Good point! >E.g., there are two valid sub-ranges in the ETen Big5 code: > START_BYTE_2_RANGES 2 > >(11) BYTE_2_RANGE rangeStart-rangeEnd > >rangeStart, rangeEnd: unsigned numbers showing the start and the end >of a sub-range validly represented by the byte 2 of the hanzi codes. > >It is required that: > 0 <= rangeStart <= rangeEnd <= 0xFF > consecutive ranges should also be in order, hence save the need to sort the range for some implementation. >(15) SEGMENT firstCode-lastCode rawBitmapFileName row x column offset > >firstCode, lastCode: unsigned number showing the first and the last >hanzi code of a valid segment of the coding space of the HBF. > >For 2-byte hanzi code, it is required that: > 0 <= firstCode <= lastCode <= 0xFFFF code ranges of consecutive segment should also be in order, hence save the need to sort the range for some implementation. >4. a fully-specified header file >ADD_STYLE_NAME "notspecial" why not ADD_STYLE_NAME "fan" [[ for fanti hanzi]] >(7) ADD_STYLE_NAME string > >ADD_STYLE_NAME is a 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. Such use seems to fit the defintion very well. E.g. Kaiti can come in either jianti or fanti, hence fanti is not a typeface classification. It is also a very useful attribute. Although the standard of GB and BIG5 specify the glyph (shape of characters), in practice there are systems which use fantizi with GB encoding. If this keyword is not suitable, perhaps we need another one. >Appendix 1: Formal Syntax of simple header file. > >unquotedString ::= char { char } . > >string ::= '"' char { char } '"' . Should we restrict "char" to be non-'"' char in these cases? Should we allow \" to mean " when quoted? >unsignedInteger ::= digit { digit } . unsignedInteger means u_int16, unsigned 16-bit integer (short) unsignedInteger32 means u_int32, unsigned 16-bit integer (long). They are ok as long as ANSI C's sscanf %i recognizes it. I'm not sure whether it is necessary to deal with integer size in Appendix 1, but it has to be mentioned. An alternative is to specify the maximum integer. Otherwise the implementation is forced to make arbitrary assumption. :-) >HBFHeaderFile ::= > 'HBFVERSION' formatVersion EOLN > 'ENCODING' stringOfEncodingScheme EOLN > 'FONT' fontName EOLN > 'FONTBOUNDINGBOX' width height xDisplacement yDisplacement EOLN > X11R5FontPropertySection > 'CHARS' totalNumberOfCharInFont EOLN ---> 'DEFAULT_CHARS unsigedInteger > HBFByte2RangeSection > HBFSegmentSection > 'ENDFONT' EOLN . make all optional number [] compulsory. this will simplify implementation (memory allocation, etc.) >offset ::= unsignedInteger . /* usually a decimal no. */ offset ::= unsignedInteger32 . >Appendix 2: Implementation > >A2.1 Application Programmer Interface (API) routines > >The implementer can define the following (abstract) data types: HBF_Buff /* HBF buffer, holding information from */ /* parsing the information in a HBF header file */ /* such as the file pointers, offset, etc. */ > HBF_Handle /* a handle to access a HBF */ >A sample implementation in Unix/C can be: > typedef FILE * HBF_Handle ; --> typedef HBF_Buff * HBF_Handle ; > >######### End of Standard for HBF ########## From eric@coeus.ucsd.edu Thu Feb 18 17:13:16 1993 Return-Path: Date: Thu, 18 Feb 1993 15:05:36 -0800 From: eric@coeus.ucsd.edu (Bo Yang) To: mcpong@uxmail.ust.hk, soft-authors@ifcss.org Subject: Re: HBF Standard proposal v0.1 Status: O Thanks for the draft, Dr. Pong. Salute for the exellent work. This is a question about the realization of simple HBF font: Does it mean that a font can be provided this way, or every font header should be complete but a HBF routine can be in-complete? I suggest to include the "FAMILY" property even in the simple HBF. When processing a document and not being able to find the exaclty identical font, it will be handy if family name is provided so a "close match" can be possibly picked. Secondly, I noticed that when printing a paragraph formated vertically, some (non-hanzi) of the characters are rotated by 90 degrees ( like all Latin alphabets, 0-9, '(', '[', etc), most are not changed( all Chinese characters), some could be shifted or remain unchanged ( like ':', '!', etc). Since most existing fonts don't provide a seperated set of rotated non-hanzi symbols, maybe a optional area should be included in the header to accomodate this. : START_ROTATED 5 A1A5 ( I made it up, let's say it stands for '[' ) A1A6 A1B0-A1B7 A3B0-A3B9 ( say, 0-9) A4C1-A4FA ( say, A-z) END_ROTATED This will be useful for those applications doing vertical formating. I feel obligated to say that X11 BDF was designed mainly for Latin char sets, then perhaps some additional properties was added to include the double-byte coded character sets. While it gives a good example to follow, we shouldn't just "patch in" some properties to make it Hanzi-compatible. Wouldn't it be better to start with thoughts on Hanzi characters from ground up, then try to make it easy to be traslated to BDF? A clean format with set of properties unique to hanzi would be elegent, compatibility with BDF should comes second, we can always leave the work to the translation program. Some properties like AVERAGE_WIDTH can be safely ignored, as it's always equal to SIZE. When transling a font to DBF, those could simply be inserted by the program. Others not seen in BDF but useful to Chinese character processing should be included. Beside the ROTATED, another one I can think of is: X_AVERAGE_STROKE_WIDTH 3 Y_AVERAGE_STROKE_WIDTH 2 This is because it's often needed to scale the bitmap up and down to get another size. ( How we envy the 7, 8 or so sets of Roman font included in X-Windows just for different sizes!) Some Chinese softwares around ( like JinShan-DOS, Twinbrige) are using some edge-smoothing argorithm when scaling the sizes up. My guess is that the average stroke width information is helpful here. The DDK for MS-Windows Chinese version also says it needs this when doing hinting for the TrueType. To conclude, we should include only those DBF or non-DBF properties that are useful for hanzi proccesing and ignore the rests, which could be added as defaults in a HBFtoBDF program. As they say, small is beautiful. -- Yang, Bo From lee@fritter.Stanford.EDU Thu Feb 18 17:13:27 1993 Return-Path: Date: Thu, 18 Feb 93 15:06:24 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: CAI@neurophys.wisc.edu's message of Thu, 18 Feb 93 15:53 CST <23021815532918@neurophys.wisc.edu> Subject: Re: Mr. LEE's comment (HBF) Status: O Dear Mr. Yidao Cai: Apology for the wording in my last message for making you feel like misunderstood. I did understand you original suggestion. Thanks for clarification again anyway. > I think you misunderstood my point here. My original suggestion was: > > a). If only one BYTE_2_RANGE, use this one for all segments. > b). If more than one BYTE_2_RANGE, the number of BYTE_2_RANGEs should > be the same as the number of segments. > > And I should add c) to make it more clear: > > c). Each BYTE_2_RANGE matches the corresponding segment if b). > > I did not say we should eliminate BYTE_2_RANGE, but simply said if we did not > specify which BYTE_2_RANGE to use for each segment, then the application > program had to decide which BYTE_2_RANGE to use according to the ENCODING. > Thus an application program could not handle an ENCODING scheme which comes > out after the application program was written, because it would have problem > deciding what BYTE_2_RANGE to use for each segment. Adding a few more lines > of BYTE_2_RANGEs could avoid this problem. > > Yidao Cai In parallel with Stephen Simpson's argument about uniform bitmap size, a uniform (applying to all SEGMENTS) BYTE_2_RANGE section as described in Draft 0.1 seems to be sufficient. I can think of one scenario where one might want it: say, include the ASCII 8x16 font together with 16x16 hanzi font in the same .hbf header file. However, this can be avoided if two .hbf files are used. I think they should be separted as two .hbf files, because the combination of ASCII font and hanzi font should really be a cross-product, e.g. Helvetica x Song, Courier x Ming, TimesItalic x Kai For variable-pitch ASCII font such as Times, HBF cannot and should not be able to handle it anyway. [[See command options for cxterm, xhzview, hz2ps.]] For programs that do not support variable-pitch ASCII fonts, they can keep on doing so. The separate specification of font files does not change the choices. Fung F. Lee From simpson@math.psu.edu Thu Feb 18 21:13:17 1993 Return-Path: From: Stephen G Simpson Date: Thu, 18 Feb 93 22:05:08 -0500 To: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) Cc: soft-authors@ifcss.org Subject: formula for the number of bytes ? Status: O Dear Dr. Pong, Another comment on the HBF 0.1 draft standard: > A full Row x Column bitmap is stored as a sequence of > Row*((Column+7)/8) bytes, where integer division with > truncation of decimal places is used in the calculation. > > E.g., > a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes > a 16x15 bitmap occupies 16*((15+7)/8) = 32 bytes > a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes This formula is certainly incorrect, because the 16x15 ET bitmaps occupy only 30 bytes each, not 32. (I assume that by 16x15 we mean width 16 and height 15, as is the case in ET. This goes back to my earlier comment about the confusion between ``size of a row'' and ``number of rows''. If we mean height 16 and width 15, then your formula could conceivably be correct in this case, as explained below -- but I don't know of any actual bitmap font with these dimensions.) What is the correct formula? Maybe it is ((W*H)+7)/8. This reduces to (W*H)/8 if W*H is a multiple of 8. The underlying assumption is that each bitmap is stored in the smallest possible number of bytes. I say ``maybe'', because I can conceive of less economical ways of storing bitmaps. For example, a 20x20 bitmap might be conveniently stored in 60 bytes, each row being stored in 3 bytes, so that the last 4 bits of every third byte would be wasted. This may actually be the case for ETen's ASCFONT.24. In my posting about the details of the ET fonts, I described ASCFONT.24 as a 16x24 font, but perhaps it would be better described as a 12x24 font in which the last 4 bits of every second byte are wasted -- either way it comes out to 48 bytes. The upshot is, we may have to consider the possibility that there is no formula for the number of bytes that is always correct. This issue has serious consequences, because the HBF file may need to specify not only the width and the height of the bitmaps but also how the bits are stored within the bytes. Stephen G. Simpson From mcpong@uxmail.ust.hk Thu Feb 18 22:08:11 1993 Return-Path: Date: Fri, 19 Feb 93 11:58:43 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: formula for the number of bytes ? Status: O > From simpson@math.psu.edu Fri Feb 19 11:06:25 1993 > > > A full Row x Column bitmap is stored as a sequence of > > Row*((Column+7)/8) bytes, where integer division with ^^^^^^^^^^^^^^^^^^^^^^^^ > > truncation of decimal places is used in the calculation. This is the definition or formula I intend in HBF Standard v1.0. Here "Row" means "no. of rows" or "height" and "Column" means "no. of columns" or "width". The consequence is that a row of bits will be stored in a MULTIPLE NO. OF 8-BIT BYTES. If the no. of bits in a row is NOT EQUAL TO multiple of 8, then a row of bits should be made to occupy full bytes (it really doesn't matter what bits '0' or '1' is in the remaining part of the last byte). > > E.g., > > a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes > > a 16x15 bitmap occupies 16*((15+7)/8) = 32 bytes ^^ > > a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes > > This formula is certainly incorrect, because the 16x15 ET bitmaps > occupy only 30 bytes each, not 32. 32 for (width x height = 15x16) bitmap incorrect. Should be 30. I copy the first line, and edit the two numbers "16" to "15", but forgot to edit "32 bytes" to "30 bytes". Sorry for the error. This could be a source of confusion. I really intend to mean the simplest case (the common case) for HBF Standard v1.0. This simplies implementation. We should forget the optimization of padding bitmaps to use every bit in the bytes of a raw bitmap file, at least in HBF Standard v1.0. > ... I can conceive of less economical ways of > storing bitmaps. For example, a 20x20 bitmap might be conveniently > stored in 60 bytes, each row being stored in 3 bytes, so that the last > 4 bits of every third byte would be wasted. This is exactly what I intend. Thanks for your clarification. mcpong P.S. I'm composing my response to other comments. From simpson@math.psu.edu Fri Feb 19 01:06:58 1993 Return-Path: From: Stephen G Simpson Date: Fri, 19 Feb 93 01:57:46 -0500 To: soft-authors@ifcss.org In-Reply-To: <9302190358.AA16056@uxmail.ust.hk> Subject: ((Width + 7) / 8) * Height Status: O Dear Dr. Pong, You wrote: > > > A full Row x Column bitmap is stored as a sequence of > > > Row*((Column+7)/8) bytes, where integer division with > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > truncation of decimal places is used in the calculation. > > This is the definition or formula I intend in HBF Standard v1.0. > > Here "Row" means "no. of rows" or "height" and > "Column" means "no. of columns" or "width". > > The consequence is that a row of bits will be stored > in a MULTIPLE NO. OF 8-BIT BYTES. If the no. of bits in > a row is NOT EQUAL TO multiple of 8, then a row of bits > should be made to occupy full bytes (it really doesn't > matter what bits '0' or '1' is in the remaining part of > the last byte). > > > > a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes > > > a 16x15 bitmap occupies 16*((15+7)/8) = 32 bytes > ^^ > > > a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes > > > > This formula is certainly incorrect, because the 16x15 ET bitmaps > > occupy only 30 bytes each, not 32. > > 32 for (width x height = 15x16) bitmap incorrect. Should be 30. No, it should be 32, as you wrote originally. 16*((15+7)/8) = 16*2 = 32, isn't that right? My confusion was caused by the fact that you are sometimes writing your bitmap dimensions as ``height x width'', while I am used to ``width x height'', which I think is more usual. In the above calculation, you were evidently talking about a width 15 height 16 bitmap (the opposite of what I thought) and this would indeed occupy 32 bytes using the padding scheme you mention (each row of bits is padded to occupy full bytes). A further source of confusion for me was that I don't know of any width 15 height 16 bitmaps, but I do know of the ET STDFONT.15 bitmaps, which are width 16 height 15 (or are they 15 x 15, either way they occupy two bytes per row for a total of 30 bytes). Anyway, now I see what you were getting at with your formula, namely each row is padded to full bytes. With that explanation, your formula is of course correct. Thanks for the clarification. Though it's not really a substantive issue, I would prefer to see your formula written as ((Width+7)/8)*Height rather than as you did. I ^^^^^^^^^^^^^^^^^^^^ think `Width' and `Height' are clearer than `Row' and `Column'. Also, I think it is more usual to write bitmap dimensions as Width x Height rather than Height x Width. However, as I say, these are not substantive issues, and any convention is OK so long as it is followed consistently. Sorry to bug you with these nit picking details. Stephen G. Simpson From @vmd.cso.uiuc.edu:FARZ@NMUMUS.BITNET Fri Feb 19 01:09:15 1993 Return-Path: <@vmd.cso.uiuc.edu:FARZ@NMUMUS.BITNET> Date: Fri, 19 Feb 93 02:00:17 EST From: FARZ000 To: Subject: HBF standard Status: O It's nice to see that a standard for Hanzi Bitmaps is on its way. Here are a few comments and they MAYBE DOS specifics: To opinion, any newly created Hanzi bitmap file should have its own header right IN the file with the first a few bytes containing a signature (something like HBF). There are several advantages. 1. It's easier to check whether the font file is corrupted. 2. When a file tries to display the bitmaps, it should be able to recogonize the font dimension without relying on a seperate description file. 3. If the font file changed (such as inserted a new section some where), the header changes aotomatically and the infomation can be used to establish the discription file. 4. Avoiding posibility that a non Hanzi file be recononized as a HBF when it happens to have the same name. This doesn't mean a seperate description file is not necessary because all those existing font files (assuming they can not be modified due to the copyright etc) have no headers. Of course these may not interfere the current draft of the standard since there are those SEGMENTS stuff to avoid anything before the real bitmaps. Regards. Roxin Zhang From mcpong@uxmail.ust.hk Fri Feb 19 01:33:07 1993 Return-Path: Date: Fri, 19 Feb 93 15:24:20 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: thanks for comments - response Status: O > Date: Thu, 18 Feb 93 10:29 CST > From: CAI@neurophys.wisc.edu > Subject: comments (HBF) > > 3. I think it would be easier for an application program if all bitmap > information for a particular encoding (say, GB) is contained in one file. > It would always be easier to deal with one file than dealing with more than > one file. Maybe this is just a silly question in real world. This is true. In some cases, e.g. CCLIB, one raw bitmap file is enough. But if we wish to use bitmap files like ETen's, then we can to use > 1 files. Hope that one day there'll be a freely available traditional (+ simplified) bitmap font. The STARTSEGMENT sections have catered for these. ------------------------------------------------------------------------- > Date: Thu, 18 Feb 93 11:17:33 -0800 > From: lee@fritter.stanford.edu (Fung Fung Lee) > Subject: Why HBF ? (Was Re: more programs in /software/fonts/d) This mail summarizes well "Why HBF is a better idea". I like point 8 most: > 8. If for some reasons, some bitmap files are missing, say > less-frequently used hanzi of kai48x48, or user-defined font files > are to be added, users can easily adjust by editing the HBF files > without changing the application programs. ------------------------------------------------------------------------- > Date: Thu, 18 Feb 93 13:13:30 -0800 > From: lee@fritter.stanford.edu (Fung Fung Lee) > To: soft-authors@ifcss.org > Subject: Re: comments (HBF) > > First, we definitely still want to keep BYTE_2_RANGE. > Second, ENCODING as defined in draft 0.1 is not totally redundant, > because "ETen Big5 v2.x" contains more information than what > one can infer from BYTE_2_RANGE. An inference is still an inference, > we can still not be 100% sure that the encoding is really GB or BIG5, > or yet something newly invented. I think that we should keep both BYTE_2_RANGE and ENCODING. Once certain accepted HBF header files ("HBF files" for short) are created for some common "raw bitmap files" (e.g. CCLIB, ETEN's), any new HBF files can be edited based on the existing ones. The BYTE_2_RANGE information can be retained/copied directly, if nothing is changed. Thus, it is not a big deal to specify in HBF files and parse those BYTE_2_RANGE lines in any implementation. (From the software engineering point of view :-) it is also nice to have the information of BYTE_2_RANGE documented in the HBF file. This saves us to find out the information elsewhere if only ENCODING is used. The main issue probably is what do we mean by ENCODING. Commonly we talk about GB and BIG5. GB here means GB2312-80. There are other GBxxxx-xx, say, for traditional hanzi. BIG5 probably is not a standard. (Any reference? I don't know any, apart from the vendor's font files.) There is the standard CNS 11643-1986 in Taiwan which appears later than Big5. I am not fluent in the various font files delivered by the various vendor; e.g. ETen, KuoChiao (spelling?), ... etc. Though they are based on so-called Big5, they may vary a little bit in the no. of character glyphs, especially in the coding space for the special symbols. Thus, if I am going to use a certain set of font files, say, ETen's, and I really want to use its special symbols as well, I should follow ALL the hanzi code of the font files. Thus I used the example of ENCODING "ETen Big5 v2.x" (To be precise, I should write v2.0 instead of v2.x, meaning a particular version, not a family of versions. Different versions in the family of versions may have different no. of glyphs!) > I know it is perhaps not useful for many programs. However, Ricky proposed > to use ENCODING for a more powerful font server. The server can look into > the directory and picks the fonts with the right encoding. In this case, > it is a must to know the ENCODING, but it is more important to match > "Big5" than "ETen v2.x". Actually there could be minor variation > among the various GB versions of DOS. Hence, to facilitate this possible > usage, let's give (1) an ordering to the words within the quoted string, > or (2) to eliminate vendor specific information, or (3) create another keyword: > It seems (1) is the simplest. I also like this idea of matching a font by giving (possibly incomplete) information; this is what X11 font server trying to do. Maybe the keyword ENCODING Big5 should be used in this sense; and my use of ENCODING "ETen Big5 v2.0" should be renamed as FONTSOURCE "ETen Big5 v2.0" ^^^^^^^^^^ [[ any better name? It's more than FOUNDRY. ]] I hope I have described the 2 separate issues clearly, recap: (1) One use is to use ALL hanzi code (glyph) appeared in a particular [set of] "raw bitmap file(s)". (2) One use is to use ONLY THOSE hanzi code defined by a certain "hanzi code standard"; e.g. GB2312-80, CNS11643-1986, ISO10646-xx-HanCharSet; BUT NOT Big5, because there seems to be so many version of Big5. One way to get away with this possible confusion is to use one keyword ENCODING which means (2) only. (The FONTSOURCE "systemName version" line is orthogonal to this.) Then, e.g., normally one would say: ENCODING "CNS11643-1986" FONTSOURCE "ETen Big5 v2.0" If one wishes to use system-specific or user-defined hanzi code which is not in the registered hanzi code standards (i.e. case (1), then one can use another HBF header file with the lines likes ENCODING "Eten Big5 v2.0" <-- seems both are necessary? FONTSOURCE "ETen Big5 v2.0" <-- seems both are necessary? ------------------ Another issue: > Stephen Simpson also pointed out whether it is worthwhile to over-complicate > (or enhance :-)) the standard by allowing different bitmap sizes in > different segments. The example given by M. C. Pong about mixing > CCLIB.16 (GB ordeing) and ETen 16x15 (BIG5 ordering) seems not too > convincing. I'm not sure which ways I should vote yet. More examples are > welcome. I am developing a version of X11R5 BDF to be used in cxterm/X11R5 to display both simplified and traditional hanzi simultaneously. I currently call the hanzi code scheme "HKUST Extended Big5" or "HKUST-EB5" because it is based on "ETen Big5 hanzi code set" (as defined by ETen font files), & uses the unallocated hanzi codes in ETen Big5 coding space to represent simplified hanzi. To be in line with using existing font filess (to avoid copyright problem etc.), I foresee that with "w h xDisp yDisp" in SEGMENT, I can write something like SEGMENT firstCode-lastCode "CCLIB" 0 16 16 0 -2 SEGMENT 0xA440-0xC67E "STDFONT.15" 0 16 15 0 -1 ... That's the motivation for including "w h xdisp ydisp" attributes in the SEGMENT line. If there are strong feeling against this, or a better solution can be used to solve this problem, I am happy to ignore "w h xd yd" attributes in SEGMENT. ------- (Creating a Unicode-v1.x raw bitmap file does not solve my problem, because cxterm and celvis can't handle unicode in the ranges 0x00??-0x0f??, 0x80??-0x8f?? --- cxterm & celvis is designed to work with one ASCII + one HANZI font.) One can make a raw bitmap file for EB5 hanzi, where only 16x16 bitmaps are used. That is, the existing ETen 16x15 bitmaps are not used -- but that seems to be moving away from the philosophy of HBF. > Since this is controvesial, I would like to make the following proposal: > change the ordering of the attributes in SEGMENT so that it becomes > > SEGMENT firstcode-lastcode bmfile offset width height xdisp ydisp > > e.g. > SEGMENT 0xA140-0xA3BF "SPCFONT.15" 0 16 15 0 -1 > SEGMENT 0xA440-0xC67E "STDFONT.15" 0 16 15 0 -1 > SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.15" 0 16 15 0 -1 > SEGMENT 0xC940-0xF9FE "STDFONT.15" 162030 16 15 0 -1 If "w h xdisp ydisp" will be accepted, we can make these optional with formal syntax: 'SEGMENT' firstcode '-' lastcode bmfile offset [ w h xdisp ydisp ] e.g. FONTBOUNDINGBOX 16 16 0 -2 ... SEGMENT firstCode-lastCode "CCLIB" 0 ^^^^^^^^^ ^^^^^^^^ ^^^^^^^^^ /* segment range * /* omitted => use */ * irrelevant here */ * FONDBOUNDBOX's */ SEGMENT 0xA440-0xC67E "STDFONT.15" 0 16 15 0 -1 SEGMENT 0xC940-0xF9FE "STDFONT.15" 162030 16 15 0 -1 ^^^^^^^^^^ /* different from * * FONDBOUNDBOX's */ ------------- Another point: > There are many practical advantages of not having separate header files ^^^^^^^^^^ I suppose U mean "having" :-) > and bitmap files, such as saving disk spaces, > avoiding possible copyright infringement, providing flexibility for > user-defined fonts, etc. > Please see my article titled "Why HBF?" posted today. ------------------------------------------------------------------------- > Date: Thu, 18 Feb 1993 15:05:36 -0800 > From: eric@coeus.ucsd.edu (Bo Yang) > Subject: Re: HBF Standard proposal v0.1 > > This is a question about the realization of simple HBF font: Does it mean that > a font can be provided this way, or every font header should be complete but > a HBF routine can be in-complete? All the glyph bitmaps are in the "raw bitmap file(s)". Either a simple or fully specified HBF header file can be used to access the glyph bitmaps using the API routines, say, HBF_OpenFont(HBFheaderFileName). The fully specified HBF header file is intended for compatibility with X11R5 font format and any font servers. In the PC environment, simple HBF header file can be used (of course, the "raw bitmap file" referenced must be in the target system as well). Hope that with no confusion, we can simple say "HBF file" to mean the "HBF header file" > I suggest to include the "FAMILY" property even in the simple HBF. When > processing a document and not being able to find the exaclty identical > font, it will be handy if family name is provided so a "close match" can be > possibly picked. I don't object to move X11R5 FAMILY_NAME properties from "fully specified HBF file" to "simple HBF file". However, others may think of some useful application of other X11R5 BDF properties as well. For example, the WEIGHT_NAME and AVERAGE_WIDTH properties are actually somewhat similar, at least in its goals, to the suggested X_AVERAGE_STROKE_WIDTH & Y_AVERAGE_STROKE_WIDTH. It seems a good idea if the following principle is followed: (1) For simple (simplest?) implementation, use "simple HBF file". (2) For more sophisticated usage, use "fully specified HBF file". The application can do more based on the information stored in the fully specified HBF file. This is actually like what the X11R5 font & font server does. A utility program, say, sHBF2fHBF, can be used to converted a simple HBF to a fully specified HBF with the addition of attributes specified by command line parameters or default values or by whatever means (popup dialog, etc.). > Secondly, I noticed that when printing a paragraph formated vertically, > some (non-hanzi) of the characters are rotated by 90 degrees ( like all Latin > alphabets, 0-9, '(', '[', etc), most are not changed( all Chinese characters), > some could be shifted or remain unchanged ( like ':', '!', etc). Since most > existing fonts don't provide a seperated set of rotated non-hanzi symbols, > maybe a optional area should be included in the header to accomodate this. : > > START_ROTATED 5 > A1A5 ( I made it up, let's say it stands for '[' ) > A1A6 > A1B0-A1B7 > A3B0-A3B9 ( say, 0-9) > A4C1-A4FA ( say, A-z) > END_ROTATED > > This will be useful for those applications doing vertical formating. I would prefer that the rotation of bitmap (by 90 degrees, or other angle) be done by the application; not specified as a **property** of HBF. In this regard, for some commonly useful operations, say rotate 90 degrees, we can provide the following API routines (should be added to draft v0.2): PtrHBF_Octet HBF_GetBitmapRotated90( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap rotated for 90 degrees anticlockwise * for a given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * NULL if invalid hanzi code or invalid HBF handle. */ PtrHBF_Octet HBF_GetBitmapRotated270( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap rotated for 270 degrees anticlockwise * for a given hanzi code. * RETURN the pointer to the bitmap of the hanzi; * NULL if invalid hanzi code or invalid HBF handle. */ Anyone wants HBF_GetBitmapRotated180(:-)? > Wouldn't it be better to start with thoughts on Hanzi > characters from ground up, then try to make it easy to be traslated to BDF? > A clean format with set of properties unique to hanzi would be elegent, > compatibility with BDF should comes second, we can always leave the work > to the translation program. I must admit that the influence of BDF on me (and others?) is great. As said above, many of the BDF properties have been found useful in display, typography (printing), etc. (One has to read the 2 references in draft v0.1 to understand more the full details.) Though in the fully specified HBF file example in draft v0.1, all BDF properties are given. Actually, most of them can be omitted. The simplest becomes the simple HBF file. The main characteristics of a hanzi font is that it should be fixed pitch. Thus it seems the FONTBOUNDBOX is good enough to use a HBF with an ASCII font (the yDisp to cope with the descent of ASCII letters); and maybe the (w h xDisp yDisp) attributes in SEGMENT are also useful in case really have somewhat different bitmap sizes for all the glyphs in a HBF. Afterall, X11R5 is no longer for Latin set of characters, but for oriental languages as well. X Consortium has put into a lot of effort to make the font & font server concept work for displaying, printing, ... etc., under sophisticated and not so sohisticated environment. -------- Another influence is that if HBF can be converted to BDF easily, then we don't need to do much to have X11 supporting HBF. This is minor, comparing with the above point. But it could save us a lot of effort in implementation as well. Another point is that if something (like BDF) is really good enough to a certain extent, it is better to use it then inventing the wheel. Hope that I can bring my point clear; I don't mean to reject your valuable comments totally. > Some properties like AVERAGE_WIDTH can be safely ignored, as it's always > equal to SIZE. When transling a font to DBF, those could simply be inserted > by the program. Others not seen in BDF but useful to Chinese character > processing should be included. Beside the ROTATED, another one I can think of > is: > > X_AVERAGE_STROKE_WIDTH 3 > Y_AVERAGE_STROKE_WIDTH 2 > > This is because it's often needed to scale the bitmap up and down to > get another size. ( How we envy the 7, 8 or so sets of Roman font included in > X-Windows just for different sizes!) Some Chinese softwares around ( like > JinShan-DOS, Twinbrige) are using some edge-smoothing argorithm when scaling > the sizes up. My guess is that the average stroke width information is > helpful here. See above. (X11R5 has also considered scalable fonts already.) Also, like compressed bitmap, I think scalable outline font should be left for HBF Standard v2.0 or later. -------- m c pong From mcpong@uxmail.ust.hk Fri Feb 19 02:59:51 1993 Return-Path: Date: Fri, 19 Feb 93 15:09:25 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: width height, NOT column row Status: O > From simpson@math.psu.edu Fri Feb 19 14:59:46 1993 > > ... I would prefer to see your > formula written as ((Width+7)/8)*Height rather than as you did. I > ^^^^^^^^^^^^^^^^^^^^ > think `Width' and `Height' are clearer than `Row' and `Column'. > > ... > > Sorry to bug you with these nit picking details. Thank you. I totally agree that "width" and "height" are clearer than "row" and "column". I also totally agree that a document should use consistent terms. It's nice to have reviewers for the draft so that we can make it a high quality standard document. This will be changed in draft v0.2; and in future mail -- hope I'm conscious of that when I write mail :-) Thank you very much; I don't think it's bugging me :-) m c From simpson@math.psu.edu Fri Feb 19 08:34:27 1993 Return-Path: From: Stephen G Simpson Date: Fri, 19 Feb 93 09:25:27 -0500 To: soft-authors@ifcss.org Subject: padding rows, ((w+7)/8)*h Status: RO In light of the discussion with M. C. Pong, I realized that all of the ET fonts follow the padding convention he mentioned, i.e. rows within a bitmap are padded to full bytes. This necessitated minor changes in my description of the ET fonts. The revised document is available for anonymous ftp at math.psu.edu:/pub/simpson/chinese/etfonts.txt. Xiaofei, do you want to put this in ifcss.org:/software/fonts/d? From lee@fritter.Stanford.EDU Sun Feb 21 02:12:36 1993 Return-Path: Date: Sun, 21 Feb 93 00:03:09 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Defintions of EOLN and Why HBF Files Should Contain No Bitmap Status: O In Appendix A.1 of HBF Draft 0.1, the definition of EOLN says that it can be one of 3 possibilities. I think the intention is to reflect the differences in UNIX, DOS and Mac, etc. It seems that such definition should encourage portability across multiple operating system platforms. I will argue that this is not necessarily be the case. ************************************************************************** Instead it is better to define the EOLN (line termination) token as the host operating system defines it. A stronger implication is that a HBF header file should be a TEXT file, containing NO raw bitmap. ************************************************************************** Why? The reasons are: 1. A HBF file can be displayed and edited as conveniently as any other TEXT file. It would be pretty awkward to edit a file with '\r' as the "EOLN" token in UNIX. Of course, you could have filtered the file before editing, and that's why I said it would be "awkward". 2. When HBF files are transfered from one (machine) OS to another one, standard text conversion can be easily done. Supposedly two identical HBF files would not be reported as different (by "diff" in UNIX, e.g.) just because of variations of EOLN. Yes, you could write your own filter or own "diff". But that's exactly what I want to avoid doing. If HBF files are TEXT files, they should not require any different tools for simple tasks like comparison. 3. If raw bitmaps were included as part of a HBF file, simple standard TEXT conversion of HBF files cannot be done, because the bitmaps are binary. Blind substitution would corrupt the data. 4. If raw bitmaps were included as part of a HBF file, the SEGMENTS offset might be wrong when the HBF file were ported from one OS to another, because (i) in the case of system-dependent EOLN, the file size might change, and (ii) in the case of multiple values of EOLN, the offsets might also need to be changed (manually) because two supposedly identical files could be different because of different choices of EOLN values. 4. If raw bitmaps were included as part of a HBF file, even one additional COMMENT line will force a change of the offset values (assuming header information is in the "header", i.e., beginning of a file). This is bad even if there is no portability issue to worry. 5. When font size gets larger (48x48, 64x64), there are many reasons why you don't want to keep the bitmaps all in one huge file, and you are forced to take care of two or more files anyway, so bundling header information and bitmaps in one file is no going to work all the time. 6. In many implementations such as CCDOS, Mac's Chinese OS, the header information is usually not something supposed to be easily editable by users. I think HBF's philosophy should be just exactly opposite. As for implementation, clearly the OS-dependent definition of EOLN is easier to implement: C's fgets() gets the line appropriately if EOLN is the expected OS-dependent value. Fung F. Lee From lee@fritter.Stanford.EDU Sun Feb 21 02:30:44 1993 Return-Path: Date: Sun, 21 Feb 93 00:24:55 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Re: HBF Standard proposal v0.1 Status: O >Date: Thu, 18 Feb 1993 15:05:36 -0800 >From: eric@coeus.ucsd.edu (Bo Yang) > >Secondly, I noticed that when printing a paragraph formated vertically, >some (non-hanzi) of the characters are rotated by 90 degrees ( like all Latin >alphabets, 0-9, '(', '[', etc), most are not changed( all Chinese characters), >some could be shifted or remain unchanged ( like ':', '!', etc). Since most >existing fonts don't provide a seperated set of rotated non-hanzi symbols, >maybe a optional area should be included in the header to accomodate this. : > >START_ROTATED 5 >A1A5 ( I made it up, let's say it stands for '[' ) >A1A6 >A1B0-A1B7 >A3B0-A3B9 ( say, 0-9) >A4C1-A4FA ( say, A-z) >END_ROTATED > >This will be useful for those applications doing vertical formating. Yes, that will be useful. Actually for vertical formating, one need more information than that in order to make the printout look good. For example, see the routines GBvtest(), BIGvtest(), GBreplace(), BIGreplace() of "hz2ps version 2.1 (July 3, 1992)" and "hz2ps.pro". However, I think we should keep HBF simple, at version 1.0 very simple and basic. Additional features such as compression, ROTATE can always be added later if necessary. HBF version 1.0 library routines should be simple to write and conform completely to the spec. One way to ensure that is the simplicity of the spec itself, in terms of both syntax and synmantics. Observing the standardization process of SCI (Scalable Coherent Interface), I learned that having an implementation ready before the standard is approved is a great idea. It helps to discover "all" the bad things about a proposed standard before it is approved. Fung F. Lee From eric@coeus.ucsd.edu Sun Feb 21 05:15:56 1993 Return-Path: Date: Sun, 21 Feb 1993 03:09:02 -0800 From: eric@coeus.ucsd.edu (Bo Yang) To: lee@fritter.stanford.edu, soft-authors@ifcss.org Subject: Re: HBF Standard proposal v0.1 Status: O Dr. Pong writes: >> From: eric@coeus.ucsd.edu (Bo Yang) >> >> I suggest to include the "FAMILY" property even in the simple HBF. When >> processing a document and not being able to find the exaclty identical >> font, it will be handy if family name is provided so a "close match" can be >> possibly picked. >I don't object to move X11R5 FAMILY_NAME properties from "fully specified >HBF file" to "simple HBF file". However, others may think of some useful >application of other X11R5 BDF properties as well. For example, >the WEIGHT_NAME and AVERAGE_WIDTH properties are actually somewhat >similar, at least in its goals, to the suggested X_AVERAGE_STROKE_WIDTH >& Y_AVERAGE_STROKE_WIDTH. It seems to me that the the usual font-matching precedures follow, in order of importance, of those: a) match the encoding of char-sets. Of all those succeded, b) match the family name. Of all those succeded, c) match the face name. Then, d) for bitmap fonts, size ( provided that scaling is convinient). e) other geometric properties. Since we are providing a), c), d) in simple HBF and e) in fully specified HBF, I think it's natural to include b) in the first group. >(1) For simple (simplest?) implementation, use "simple HBF file". >(2) For more sophisticated usage, use "fully specified HBF file". > The application can do more based on the information stored > in the fully specified HBF file. > This is actually like what the X11R5 font & font server does. > A utility program, say, sHBF2fHBF, can be used to converted > a simple HBF to a fully specified HBF with the addition of > attributes specified by command line parameters or default > values or by whatever means (popup dialog, etc.). I see your point, the properties outside of simple HBF will actually contain: a) those used by Hanzi but not important, like SIZE, WEIGHT_NAME. and those not used by Hanzi but used by DBF. Of which: b) those can be inserted by defaults for ALL fonts, i.e., properties of Hanzi but not of a particular font, like SPACING. c) those can be figured out easily from other useful properties by rigid rules, like AVERAGE_WIDTH. I meant to suggest reducing b) part. But seems V0.1 has minimal ( 0, strickly speaking) of these, I'm happy with the proposed specification. >I would prefer that the rotation of bitmap (by 90 degrees, or other angle) >be done by the application; not specified as a **property** of HBF. >In this regard, for some commonly useful operations, say rotate 90 degrees, >we can provide the following API routines (should be added to draft v0.2): > PtrHBF_Octet HBF_GetBitmapRotated90( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); >... It's difficult to tell if this is a property of the encoding in applications or that of a font. But we can always leave it to future versions. >> Wouldn't it be better to start with thoughts on Hanzi >> characters from ground up, then try to make it easy to be traslated to BDF? >> A clean format with set of properties unique to hanzi would be elegent, >> compatibility with BDF should comes second, we can always leave the work >> to the translation program. >I must admit that the influence of BDF on me (and others?) is great. >As said above, many of the BDF properties have been found useful in >display, typography (printing), etc. (One has to read the 2 references >in draft v0.1 to understand more the full details.) >Though in the fully specified HBF file example in draft v0.1, >all BDF properties are given. Actually, most of them can be omitted. >The simplest becomes the simple HBF file. >The main characteristics of a hanzi font is that it should be fixed pitch. >Thus it seems the FONTBOUNDBOX is good enough to use a HBF with an ASCII >font (the yDisp to cope with the descent of ASCII letters); and maybe >the (w h xDisp yDisp) attributes in SEGMENT are also useful in case >really have somewhat different bitmap sizes for all the glyphs in a HBF. >Afterall, X11R5 is no longer for Latin set of characters, >but for oriental languages as well. X Consortium has put >into a lot of effort to make the font & font server concept >work for displaying, printing, ... etc., under sophisticated >and not so sohisticated environment. -------- >Another influence is that if HBF can be converted to BDF easily, >then we don't need to do much to have X11 supporting HBF. >This is minor, comparing with the above point. But it could save us >a lot of effort in implementation as well. Another point is that if >something (like BDF) is really good enough to a certain extent, it is >better to use it then inventing the wheel. Agreed. I guess it's always easier to critisize than to propose (the draft) :-) Again, I'm pleased with the specification and think we should go on pressing on it. >> processing should be included. Beside the ROTATED, another one I can think of >> is: >> >> X_AVERAGE_STROKE_WIDTH 3 >> Y_AVERAGE_STROKE_WIDTH 2 >> >> This is because it's often needed to scale the bitmap up and down to >> get another size. ( How we envy the 7, 8 or so sets of Roman font included in >> X-Windows just for different sizes!) Some Chinese softwares around ( like >> JinShan-DOS, Twinbrige) are using some edge-smoothing argorithm when scaling >> the sizes up. My guess is that the average stroke width information is >> helpful here. >See above. (X11R5 has also considered scalable fonts already.) >Also, like compressed bitmap, I think scalable outline font should be >left for HBF Standard v2.0 or later. what I meant is that these might be useful for bitmapped fonts too, especially when scaling of hanzi bitmapped fonts is a bigger issue than of the case of the Latin fonts. But this can be left for future as well. >-------- >m c pong -- Bo Yang From mcpong@uxmail.ust.hk Sun Feb 21 22:59:11 1993 Return-Path: Date: Mon, 22 Feb 93 11:26:15 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: Defintions of EOLN and Why HBF Files Should Contain No Bitmap Status: O I agree that EOLN should be left undefined, but with description in the standard that it is system dependent, in line with F.F.Lee's explanation. I'll incorporate this idea, if no strong objection. mcpong From ygz@cs.purdue.edu Mon Feb 22 23:47:10 1993 Return-Path: To: soft-authors@ifcss.org Subject: xDisp, yDisp, etc. in HDF v 0,1 Date: Tue, 23 Feb 1993 00:39:39 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O M.C. Pong suggested we add ``row column xDisp yDisp'' into the SEGMENT. The reason was that mixed size bitmap files can be used together. But I think it is over-complicated and is seldom needed in practice. One start point of HBF was to take advantage of the feature of hanzi -- fixed bitmap size. Bitmaps of different size should not co-exist in a hanzi font at the first place. For the HKUST ``extended Big5'' project, you can always normalize all the bitmaps into the largest size. --ygz From mcpong@uxmail.ust.hk Tue Feb 23 20:44:51 1993 Return-Path: Date: Wed, 24 Feb 93 10:36:12 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF - some background info Status: O For "BIG5", I can accept that it's coding range is well defined, but it is not completely **standardized**. [[ I haven't checked many versions. CCVICTOR@uxmail.ust.hk helps to supply the following information: ETen v1.x (~2 years ago?) has fewer hanzi in the "STANDARD-FONT" than ETen v2.x and ETen v3.x -- seems ETen BIG5 is stablized now. (ETen also supports a user-defined hanzi bitmap font file, which can be handled by another HBF). However, the Kuochiao (spelling?) PC system, which is also common in HK & Taiwan, has 2 hanzi codes which are different from ETen's "STANDARD-FONT". The hku-ch16 bitmap font commonly used in the X environment also has some discrepancies with ETen, though the program (et2hku) has been written to convert. We have no way to force the unification of ETen BIG5 & Kuochiao BIG5. The way out should be using CNS11643-1986 or Unicode Han v? or ISO10646. But, where is the bitmap file for these standards? Should we specify HBF first with the "theoretical best" design and wait for the bitmap files conforming to such standards? "theoretical best" means use "hanzi code standard name" only, and support "fixed pitch bitmap files" only. I can accept a "Yes" answer to the last question. :-) ]] From mcpong@uxmail.ust.hk Tue Feb 23 21:13:51 1993 Return-Path: Date: Wed, 24 Feb 93 10:23:24 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF standard 1.0 draft 0.1 Status: O I shall update the draft v0.1 soon. There're two major issues unsettled yet: (1) Should ENCODING be included in HBF header file? It seems that more people favour it. Then the question is: What should be included as the attributes of ENCODING? Two suggestions: (any more?) (1.A) simply use the hanzi code standard name e.g. GB2312-80 BIG5 (where is the standard? :-) or CNS11643-1986 (any bitmap files layout according to this?) (1.B) use a more descriptive name which specifies what bitmap files the HBF conform to. One can still use "GB2312-80" which means conforming to the standard; but also, say, the following "full" format can be used: "BIG5 ETen 2.0" ^^^ the version of the bitmap file of the system/vendor ^^^^ the system/vendor ^^^^ the hanzi code standard Using a string is simpler for matching; but regarding it as a sequence of tokens separated by space/tab can get individual attributes. API routines can be provided in the latter case to match a request of "BIG5" bitmaps (without specifying any more). [[ I favour (1.B). -- mcpong ]] -------- (2) Should (w h xd yd) attributes be allowed in the line SEGMENT? We have "FONTBOUNDINGBOX w h xd yd" already. Ideally it is enough to handle fixed size bitmap. The need for "SEGMENT w h xd yd" is to allow the use of vendor's bitmap file (which may have different w h) to avoid copyright problem. For most cases, the w h xd yd values in FONTBOUNDINGBOX & SEGMENT are the same. An example of different values is: use of 16x16 CCLIB and 16x15 ETen bitmap files to show both simplified and traditional hanzi in the same application. [[ I favour having SEGMENT w h xd yd; though I am ready to drop this idea. -- mcpong ]] -------- Please send in the last round of comments and I'll update to draft v0.2. Thanks. mcpong From Ricky.Yeung@Eng.Sun.COM Wed Feb 24 00:15:25 1993 Return-Path: Date: Tue, 23 Feb 93 22:00:55 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: mcpong@uxmail.ust.hk Cc: soft-authors@ifcss.org In-Reply-To: Dr. PONG Man Chi's message of Wed, 24 Feb 93 10:23:24 HKT <9302240223.AA18996@uxmail.ust.hk> Subject: Re: HBF standard 1.0 draft 0.1 Content-Length: 183 Status: O I think you may want to add an entry to the API to allow the retrieval of properties, something like: char* HBF_GetProperty(HBF_Handle hdl, char* property_name); -Ricky ~{QnUq8;~} From simpson@math.psu.edu Wed Feb 24 16:52:56 1993 Return-Path: From: Stephen G Simpson Date: Wed, 24 Feb 93 17:43:49 -0500 To: soft-authors@ifcss.org Subject: Bounding Box versus actual Bitmap dimensions Status: O Dr. Pong writes: > I shall update the draft v0.1 soon. > There're two major issues unsettled yet: > > (1) > Should ENCODING be included in HBF header file? > I favor including it. I prefer option 1.B as outlined by Dr. Pong. > (2) > Should (w h xd yd) attributes be allowed in the line SEGMENT? > > We have "FONTBOUNDINGBOX w h xd yd" already. > Ideally it is enough to handle fixed size bitmap. > ... > > [[ I favour having SEGMENT w h xd yd; > though I am ready to drop this idea. -- mcpong ]] I favor an intermediate or compromise proposal. MY PROPOSAL would be that, in addition to ``FONTBOUNDINGBOX w h xd yd'', we should have four additional attributes, say ``HBFINFO bw bh bxd byd'', telling (1) the actual size of the bitmaps (possibly smaller than the bounding box), and (2) how the bitmaps are to be placed within the bounding box (in case they are smaller than the bounding box). But, to answer Dr. Pong's question, I am against allowing each segment to have different attributes. In other words, the bw bh bxd byd attributes, like w h xd yd, should apply to the HBF font as a whole rather than to individual segments. I would argue that my proposal above gives us the best of everything. The original idea of HBF as against BDF was to take advantage of the fact that Hanzi fonts such as CCLIB have bitmaps of uniform dimensions. In this spirit, I don't think we want to allow different dimensions in different segments. Echoing ygz's comment, I would say that if you want to use 16x16 and 15x15 bitmaps together in the same application, use two different HBF header files. And, HERE IS MY MAIN POINT, my proposed bw bh bxd byd would make this much easier!!! For example, it would allow you to use ET's 15x15 font with a 16x16 bounding box (compatible with the CCLIB 16x16 font), just by creating a new HBF header file! In other words, we can pad a font to any size we want. In this example, the HBF header file would contain lines like FONTBOUNDINGBOX 16 16 0 -2 HBFINFO 15 15 0 0 Here we have bw = 15, bh = 15, bxd = 0, byd = 0, which would cause the 15x15 bitmap to be placed in the lower left of the 16x16 bounding box. HBFINFO 15 15 0 1 would place it one unit above the bottom of the bounding box, etc. (The yd = -2 means that the bounding box is to be placed two units below the logical line in the application output.) The point I am trying to make is: My proposal would give the flexibility to use for instance 15x15 and 16x16 fonts together in the same application WITH THE SAME SIZE BOUNDING BOX if desired. In other words, we can ``pad'' an HBF font to the size desired by changing just two lines in the HBF header file. This flexibility would be very nice indeed. I don't think even BDF allows this kind of flexibility. If you want to pad a 15x15 BDF font to 16x16, I think the only way is to create a new BDF file! (Somebody please correct me if I am wrong on this.) Of course my suggestion of ``HBINFO'' as a keyword was for illustration purposes only. Any reasonable keyword would do. My real point is that it would be very desirable to have extra attributes bw bh bxd byd as described. IMPORTANT NOTE: There is a need for both sets of attributes: w h xd yd and bw bh bxd byd. They do not duplicate each other! In API terms, HBF_getbitmap would use bw bh bxd byd internally and return only w h xd yd to the calling program. Specifically, HBF_getbitmap would return a w by h bitmap together with xd and yd as hints suggesting what the application program might want to do with the bitmap. The bw bh bxd byd attributes would be invisible to the calling program and would be used by HBF_getbitmap only in constructing the bitmap which it returns. Sorry to be so verbose, but I think that in electronic communication like this, it is important to be very clear to avoid misunderstandings. From simpson@math.psu.edu Wed Feb 24 18:21:40 1993 Return-Path: From: Stephen G Simpson Date: Wed, 24 Feb 93 19:16:06 -0500 To: soft-authors@ifcss.org Subject: ZIKU24 bitmaps Status: O I looked at the ZIKU24 bitmaps that come with BYX 1.1 and found to my dismay that they are sideways, i.e. not in the standard row major order!!! This represents a problem for HBF. I was hoping that HBF would save me some disk space on my PC, by letting me delete unwanted fonts and use existing fonts such as BYX's and ET's for my own programs. Unfortunately, the ZIKU24 fonts are not compatible with HBF! And, unfortunately, rewriting BYX 1.1 to use standard fonts is not an option, because the source code is not available, only the executables (this is the custom in the MS-DOS world). Is anyone interested in enlarging the HBF specification to allow sideways bitmaps? -- S. Simpson From mcpong@uxmail.ust.hk Wed Feb 24 23:29:44 1993 Return-Path: Date: Thu, 25 Feb 93 13:22:56 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: Bounding Box versus actual Bitmap dimensions Status: O > From simpson@math.psu.edu Thu Feb 25 06:45:40 1993 > > I favor an intermediate or compromise proposal. MY PROPOSAL would be > that, in addition to ``FONTBOUNDINGBOX w h xd yd'', we should have > four additional attributes, say ``HBFINFO bw bh bxd byd'', telling (1) > the actual size of the bitmaps (possibly smaller than the bounding > box), and (2) how the bitmaps are to be placed within the bounding box > (in case they are smaller than the bounding box). But, to answer Dr. > Pong's question, I am against allowing each segment to have different > attributes. In other words, the bw bh bxd byd attributes, like w h xd > yd, should apply to the HBF font as a whole rather than to individual > segments. I support this idea of using ``FONTBOUNDINGBOX w h xd yd'' and ``HBFINFO bw bh bxd byd''. Maybe HBFINFO should be renamed as FONTBOUNDINGBOX while the original FONTBOUNDINGBOX renamed as OUTPUTBOUNDINGBOX, because HBFINFO is actually specifying the bounding-box (bw bh bxd byd) for the font described by the HBF while (w h xd yd) becomes the bounding-box in which a glyph of the font should be placed. In most cases both bounding-boxes are the same. Thus, we can make ``FONTBOUNDINGBOX bw bh bxd byd'' (note: bw bh bxd byd, not w h xd yd) compulsory and ``OUTPUTBOUNDINGBOX w h xd yd'' optional. The use of compulsory bounding-box with keyword ``FONTBOUNDINGBOX'' is in line with X11R5 BDF. If this is accepted, then in draft v0.2, I'll rename the parameters consistently to avoid confusion (hopefully), using ``OUTPUTBOUNDINGBOX wOut hOut xdOut ydOut'' (optional) and ``FONTBOUNDINGBOX w h xd yd'' (compulsory). mcpong From mcpong@uxmail.ust.hk Wed Feb 24 23:44:30 1993 Return-Path: Date: Thu, 25 Feb 93 13:36:10 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Re: ZIKU24 bitmaps Status: O > From simpson@math.psu.edu Thu Feb 25 08:15:46 1993 > > This represents a problem for HBF. I was hoping that HBF would save > me some disk space on my PC, by letting me delete unwanted fonts and > use existing fonts such as BYX's and ET's for my own programs. > Unfortunately, the ZIKU24 fonts are not compatible with HBF! And, > unfortunately, rewriting BYX 1.1 to use standard fonts is not an > option, because the source code is not available, only the executables > (this is the custom in the MS-DOS world). > > Is anyone interested in enlarging the HBF specification to allow > sideways bitmaps? Even if we make HBF header file specify sideways bitmaps, it doesn't solve the problem of 2 sets of fonts of same attributes (family/size/...). I prefer to stick to the original rationale for having HBF, and only keep one canonical format (in row major order) of a Chinese bitmap font. When the implementation of the API routines are ready, it should be easy for an application to switch to use HBF. (There will be routines to convert a canonical bitmap to column major order.) Hopefully by that time, the authors of the applications can be convinced to make a (small) change of the program to use HBF. ----- BTW, should we rename HBF to CHBF in Standard v1.0 ==== Canonical Hanzi Bitmap Font? Simply "HBF" is not suggestive enough. or CBF = Canonical Bitmap Font or Chinese Bitmap Font ? ^^^^^^^^^^^^^^^^^^^ also appropriate for Standard v1.0 ^^^^^^^^^^^^^^^^^^^^^ One day, it may be used for fonts other than Chinese char(?) mcpong From mcpong@uxmail.ust.hk Thu Feb 25 00:45:15 1993 Return-Path: Date: Thu, 25 Feb 93 14:36:32 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: Bounding Box of HBF Status: O Some supplementary communication & clarification: > From mcpong Thu Feb 25 14:14:42 1993 > To: pklai > Subject: Re: Bounding Box versus actual Bitmap dimensions > > > From pklai Thu Feb 25 13:59:59 1993 > > To: mcpong@uxmail.ust.hk > > Subject: Re: Bounding Box versus actual Bitmap dimensions > > > > m.c. > > > > I think that it will be better to keep the semantic of FONTBOUNDINGBOX > > because it is borrow from definition in BDF. Changing it will lead to > > confusion to people familiar with BDF. > > > > I suggest to change HBFINFO to BITMAPBOUNDINGBOX or RAWBITMAPBOUNDINGBOX. > > > > pklai > > Think about the semantics of > FONTBOUNDINGBOX in BDF: > it's about the (largest) boundingbox of all glyphs in the font. > > In HBF, what HBFINFO means is exactly BDF's FONTBOUNDINGBOX; > ^^^^^^^^^^^^^^^^^^^^^ > while Simpson's FONTBOUNDINGBOX actually means in what boundingbox > a glyph should be placed; thus I suggest calling it "OUTPUTBOUNDINGBOX". > > I have thought about keeping Simpson's FONTBOUNDINGBOX as "FONTBOUNDINGBOX" > and HBFINFO as "BITMAPBOUNDINGBOX", but see last paragraph. > > Thus I propose keeping "FONTBOUNDINGBOX w h xd yd" for HBF (compatible with > BDF) and optional "OUTPUTBOUNDINGBOX wOut hOut xdOut ydOut" for specifying > the returned bitmap in API routines, if different from FONTBOUNDINGBOX. > > m c From simpson@math.psu.edu Thu Feb 25 02:30:52 1993 Return-Path: From: Stephen G Simpson Date: Thu, 25 Feb 93 03:23:03 -0500 To: soft-authors@ifcss.org In-Reply-To: <9302250522.AA19111@uxmail.ust.hk> Subject: Re: Bounding Box versus actual Bitmap dimensions Status: O >From me: > > I favor an intermediate or compromise proposal. MY PROPOSAL would be > > that, in addition to ``FONTBOUNDINGBOX w h xd yd'', we should have > > four additional attributes, say ``HBFINFO bw bh bxd byd'', telling (1) > > the actual size of the bitmaps (possibly smaller than the bounding > > box), and (2) how the bitmaps are to be placed within the bounding box > > (in case they are smaller than the bounding box). But, to answer Dr. > > Pong's question, I am against allowing each segment to have different > > attributes. In other words, the bw bh bxd byd attributes, like w h xd > > yd, should apply to the HBF font as a whole rather than to individual > > segments. >From Dr. Pong: > I support this idea of using ``FONTBOUNDINGBOX w h xd yd'' > and ``HBFINFO bw bh bxd byd''. > > Maybe HBFINFO should be renamed as FONTBOUNDINGBOX > while the original FONTBOUNDINGBOX renamed as OUTPUTBOUNDINGBOX, > because HBFINFO is actually specifying the bounding-box (bw bh bxd byd) > for the font described by the HBF while (w h xd yd) becomes the > bounding-box in which a glyph of the font should be placed. Now from me again: In choosing keywords for font attributes, we should be careful not to conflict with the BDF standard. In particular, FONTBOUNDINGBOX in HBF should denote exactly the same attributes as in BDF. If we convert an HBF file to a BDF file (using R. Yeung's proposed hbf2bdf program), the FONTBOUNDINGBOX lines in the two files should be identical. I am not an expert on X windows and BDF, but my impression is that FONTBOUNDINGBOX information is passed to X application programs (so-called ``clients''), while the placement of glyphs within the bounding box is a matter internal to the X font server. My HBINFO attributes would not be passed to applications, rather they would be used internally by HBF API routines such as getbitmap. Referring to my earlier example, the application program is not aware that it is receiving 15x15 bitmaps inside a 16x16 box, rather it is aware only of the 16x16 box. >From this perspective, it would seem that my HBFINFO is very different from BDF's FONTBOUNDINGBOX, so the renaming you propose seems confusing. But I am really not sure about BDF's FONTBOUNDINGBOX, can anyone enlighten me? My point is that it would be confusing for FONTBOUNDINGBOX to mean one thing in a BDF file and another thing in an HBF file, so we should be very careful that we understand the BDF usage. As a general rule governing the relationship between HBF and BDF, I would propose that an HBF font may optionally include all the information needed to construct a BDF font, and that this information should be specified by exactly the same keywords as in the BDF file. Any additional HBF information should be specified by new keywords which are unique to HBF. (Maybe these new keywords should all begin with the letters HBF, as in HBFINFO.) In this way, HBF will not conflict with BDF. -- S. Simpson From simpson@math.psu.edu Thu Feb 25 02:37:16 1993 Return-Path: From: Stephen G Simpson Date: Thu, 25 Feb 93 03:30:10 -0500 To: soft-authors@ifcss.org Subject: an ugly implementation Status: O /* HBF.C -- crude implementation of the HBF getbitmap function Stephen G. Simpson February 24, 1993 This is an extremely crude, primitive implementation of the HBF getbitmap function. I know that this code is disgusting in many ways, but perhaps some of it can be used by other people. I have tested it and am using it for my Chinese character flashcard program, FLASH, written in Turbo C 2.0 under MS-DOS on an IBM PC clone. Some ``features'' (mostly limitations) of the HBF getbitmap function below are: 1. The calling program passes the width and height of the desired bitmap as well as a buffer big enough to hold the bitmap (i.e. at least ((width+7)/8)*height bytes). In addition, the calling program passes a Chinese character code (struct ccode) and a string naming an HBF header file. The getbitmap function returns 1 or 0 indicating success or failure in finding a bitmap of the specified dimensions. If unsuccessful, it draws a box of the specified dimensions. 2. This getbitmap function is assuming the format of the sample HBF 0.8 header files supplied by F. F. Lee. 3. This getbitmap function reads and caches the following information for each font used: FONTBOUNDINGBOX width and height, LOW_BYTE_RANGE information, and SEGMENT information (segment ranges, names of bitmap files, pointer to these files, and offsets within the files). In this crude implementation, it is assumed that the width and height of the actual bitmaps are as specified by FONTBOUNDINGBOX. 4. The bitmaps themselves are not cached in memory. Rather, they are read in only as needed. I know this is very slow, but FLASH is not time sensitive -- it displays Chinese characters interactively, a few at a time. Besides, I want FLASH to run on MS-DOS machines with minimal memory, say 256 K. Other HBF implementations will probably want to cache bitmap files in memory for speed, as in F. F. Lee's excellent hz2ps program. 5. The worst feature of this implementation is that it is limited to a fixed number of HBF fonts, low byte ranges, and segments (specified below in #define's). Surely other HBF implementations will use malloc to accommodate an unlimited number of fonts, etc. */ #include #define MAXHBF 5 /* maximum number of HBF fonts used */ #define MAXSEG 10 /* maximum number of segments in a font */ #define MAXLBR 2 /* maximum number of low byte ranges in a font */ #define MAXFILEPATH 160 /* maximum length of a file path */ #define MAXLINE 240 /* maximum size of line in HBF header file */ struct ccode { unsigned char high, low; }; static void drawbox(unsigned char* buf, int width, int height); int getbitmap(unsigned char* buf, int w, int h, char* hbfpath, struct ccode c) { static int firsttime = 1; static FILE *seg [MAXHBF] [MAXSEG]; static char hbfname [MAXHBF] [MAXFILEPATH+1]; static int width[MAXHBF], height[MAXHBF], size[MAXHBF]; static int lbrsum [MAXHBF], lbrindex [MAXHBF] [MAXLBR]; static int startlbr [MAXHBF] [MAXLBR], endlbr [MAXHBF] [MAXLBR]; static char segname [MAXHBF] [MAXSEG] [MAXFILEPATH+1]; static long startseg [MAXHBF] [MAXSEG], endseg [MAXHBF] [MAXSEG]; static long offset [MAXHBF] [MAXSEG]; FILE *f; char line [MAXLINE+3], filepath [MAXLINE+3]; int p, r, s, n, c1, c2, ss1, ss2; long index, cnum; if (firsttime) { firsttime = 0; for (p = 0; p < MAXHBF; p++) { hbfname[p][0] = '\0'; for (r = 0; r < MAXLBR; r++) startlbr[p][r] = 0, endlbr[p][r] = -1, lbrindex[p][r] = 0; for (s = 0; s < MAXSEG; s++) startseg[p][s] = 0, endseg[p][s] = -1, offset[p][s] = 0; } } for (p = 0; p < MAXHBF; p++) { if (strcmp(hbfname[p], hbfpath) == 0) break; if (hbfname[p][0] == '\0' || p == MAXHBF - 1) { if (strlen(hbfpath) > MAXFILEPATH) { drawbox(buf, w, h); return(0); } strcpy(hbfname[p], hbfpath); if ((f = fopen(hbfname[p], "r")) == NULL) { fclose(f); drawbox(buf, w, h); return(0); } r = -1; s = -1; lbrsum[p] = 0; while (fgets(line, MAXLINE, f)) { if (strncmp(line, "FONTBOUNDINGBOX", 15) == 0) { sscanf(line, "%*s %i %i", &width[p], &height[p]); size[p] = ((width[p]+7)/8)*height[p]; } if (strncmp(line, "LOW_BYTE_RANGE", 14) == 0 && ++r < MAXLBR) { lbrindex[p][r] = lbrsum[p]; sscanf(line, "%*s %i-%i", &startlbr[p][r], &endlbr[p][r]); lbrsum[p] += endlbr[p][r] - startlbr[p][r] + 1; } if (strncmp(line, "SEGMENT", 7) == 0 && ++s < MAXSEG) { sscanf(line, "%*s %I-%I %s %I", &startseg[p][s], &endseg[p][s], filepath, &offset[p][s]); if ((n = strlen(filepath)) + 3 < MAXFILEPATH) { if (filepath[n-1] == '"' && n > 0) filepath[n-1] = '\0'; if (filepath[0] == '"') n = 1; else n = 0; strcpy(segname[p][s], filepath + n); seg[p][s] = fopen(segname[p][s], "rb"); } } } fclose(f); break; } } if (w != width[p] || h != height[p]) { drawbox(buf, w, h); return(0); } c1 = (int)c.high; c2 = (int)c.low; for (r = 0; r < MAXLBR && endlbr[p][r] < c2; r++) ; if (r == MAXLBR || c2 < startlbr[p][r]) { drawbox(buf, w, h); return(0); } index = (long)lbrindex[p][r] + c2 - startlbr[p][r]; cnum = (long)c1*256 + c2; for (s = 0; s < MAXSEG && endseg[p][s] < cnum; s++) ; if (s == MAXSEG || cnum < startseg[p][s]) { drawbox(buf, w, h); return(0); } ss1 = (int)((startseg[p][s])/256); ss2 = (int)((startseg[p][s])%256); for (r = 0; r < MAXLBR && endlbr[p][r] < ss2; r++) ; if (r == MAXLBR) { ss1 += 1; ss2 = startlbr[p][0]; r = 0; } index += (long)(c1 - ss1)*lbrsum[p]; if (ss2 < startlbr[p][r]) ss2 = startlbr[p][r]; index -= (long)lbrindex[p][r] + ss2 - startlbr[p][r]; fseek(seg[p][s], offset[p][s] + index*size[p], 0); if (fread(buf, 1, size[p], seg[p][s]) == size[p]) return(1); f = fopen(segname[p][s], "rb"); fseek(f, offset[p][s] + index*size[p], 0); if (fread(buf, 1, size[p], f) == size[p]) { fclose(f); return(1); } fclose(f); drawbox(buf, w, h); return(0); } static void drawbox(unsigned char* buf, int w, int h) { /* if we can't find a bitmap, draw a box instead */ unsigned char bit[8] = { 128, 64, 32, 16, 8, 4, 2, 1 }; int u, v, size, i, j; u = (w+7)/8; v = (w+7)%8; size = u*h; /* in drawing our box, we pad each row to full bytes */ for (i = 0; i < u; i++) buf[i] = 0xff; while(i < size - u) { buf[i++] = bit[0]; for (j = 1; j < u; j++) buf[i++] = 0; buf[i-1] |= bit[v]; } while (i < size) buf[i++] = 0xff; } From Ricky.Yeung@Eng.Sun.COM Thu Feb 25 04:31:09 1993 Return-Path: Date: Thu, 25 Feb 93 02:25:02 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: soft-authors@ifcss.org Subject: SEGMENT w h xd yd Content-Length: 2122 Status: O HBF can only be successful if the software developers would actually use it. To encourage this to happen, our proposal should make the transition as smooth as possible, i.e. the least amount of required modification to the existing code. It's also important to have a proposal that is simple to implement and leave room for arguable features to slip in in the future. Now consider each segment (or effectively can be each character bitmap) has a different size. The HBF_GetBitmap call would have to return size information in addition to the bitmap. Most of the existing programs probably anticipate uniformly-sized font only. Say the program expects a 16x16 bitmap and HBF_GetBitmap returns something say a 15x13 bitmap. What should the program do? The author has four choices: (1) make it bomb out or quit; (2) rewrite to handle multiple size font; (3) add routine to pad the 15x13 to 16x16; (4) not bother with HBF at all. What do you think s/he will do? :-) My suggestion: Not supporting non-uniform size bitmap segment in the first version (see below). Leave the BOUNDINGBOX property as the same meaning as in BDF. Add a mandatory property (as proposed by some others) say BITMAPSIZE wid ht for the width and height for each bitmap (or the maximum width and height for non-uniform size bitmaps, see below). (Personally I don't like the terms like INNERBOUNDINGBOX or OUTERBOUNDINGBOX.) The pseudo API (I am lazy to create new names, so use C++ syntax and its overloading notation here): (1) void HBF_GetBitmapSize(HBF_Handle, int& width, int& height); (2) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&); For HBF n.0, if it's decided to support different size bitmap segments, a new API could simply be added: (3) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&, int& width, int& height); In this version of the library, HBF_GetBitmapSize returns the maximum width and height of all the bitmaps; HBF_GetBitmapSize(3) returns additional info for individual bitmap; and HBF_GetBitmap(2) automatically pads the bitmap to the width and height returned by (1). -Ricky From CAI@neurophys.wisc.edu Thu Feb 25 10:54:04 1993 Return-Path: Date: Thu, 25 Feb 93 10:42 CST From: CAI@neurophys.wisc.edu Subject: ZIKU24, CHBF and more To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O I think we should not make HBF too complicated at this stage. I agree with mcpong that we shoul stick to the original order and should not worry about ZIKU24 in BYX very much. Once a standard is set, the author of BYX may be willing to change, it is not a difficult job and it does cost much anyway. If he did not change, the users may complain to hi, or they can turn away, for example, switch to NJSTAR. After we have tried the standard, and we found there is indeed a need for another order, we can easily put it on in the next version. But if we do it now, we are never going to have a nicc, simple and clean standard. For mcpong's proposed change of HBF to CHBF, it is not needed at all once you specified what order you have used. If one did not bother to read the standard, he is not going to use it anyway. Another reason for not using CHBF is that most people may want to name the HBF file as *****.hbf but not *****.chbf, which is not allowed on PC. CBF can be even worse, does C stand for Chinese or Canonical as you intended to ? Once again, we can leave those non-essential-but-disputable things to the next version. Once we begin working with HBF, we may find the original reasoning for something might be not very useful in practice. I also have an implantation of HBF ready on my CNPRINT, but it too ugly to be posted on this discussion net (by the way, I think Simpson's implantation is not ugly at all). I think the most important things are the segments, offset, bitmap size and byte-2-ranges. The last thing: v0.1 used STARTSEGMENTS, STARTPROPERTIES, but why START_BYTE_2_RANGES ? Why not STARTBYTE_2_RANGES ? Just curious, it does not hurt at all. I noticed that when I worked on the implantation. I gave me an error message. Then I said to myself I should be more careful to follow the standard. Yidao Cai From jiang Thu Feb 25 12:24:27 1993 Return-Path: Date: Thu, 25 Feb 93 12:19:17 CST From: jiang (Yuan Jiang) To: soft-authors Subject: Re: ZIKU24, CHBF and Status: O Some software authors intentionally rearranged the format of the font from CCDOS or other sources to avoid copyright complications. So, if fonts conform to a standard are widely available, it will free a lot programmers energy in struggling with fonts and copyright issues. From lee@fritter.Stanford.EDU Thu Feb 25 13:07:32 1993 Return-Path: Date: Thu, 25 Feb 93 11:01:03 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Ricky Yeung's message of Thu, 25 Feb 93 02:25:02 PST <9302251025.AA23505@hk.Eng.Sun.COM> Subject: SEGMENT w h xd yd Status: O >Date: Thu, 25 Feb 93 02:25:02 PST >From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) >Content-Length: 2122 > > >HBF can only be successful if the software developers would actually use >it. To encourage this to happen, our proposal should make the >transition as smooth as possible, i.e. the least amount of required >modification to the existing code. It's also important to have a >proposal that is simple to implement and leave room for arguable >features to slip in in the future. > >Now consider each segment (or effectively can be each character bitmap) >has a different size. The HBF_GetBitmap call would have to return size >information in addition to the bitmap. Most of the existing programs >probably anticipate uniformly-sized font only. Say the program expects >a 16x16 bitmap and HBF_GetBitmap returns something say a 15x13 bitmap. >What should the program do? The author has four choices: (1) make it >bomb out or quit; (2) rewrite to handle multiple size font; (3) add >routine to pad the 15x13 to 16x16; (4) not bother with HBF at all. What >do you think s/he will do? :-) Good point. Many people have expressed that they don't want HBF to be more complicated than necessary. Considering the practical implications as pointed out by Ricky, I am finally convinced that HBF v1.0 should stick to its original goal of supporting one uniform-sized bitmap font with multiple segments. >My suggestion: > >Not supporting non-uniform size bitmap segment in the first version (see >below). > >Leave the BOUNDINGBOX property as the same meaning as in BDF. Add a >mandatory property (as proposed by some others) say > Completely agreed. >BITMAPSIZE wid ht > >for the width and height for each bitmap (or the maximum width and >height for non-uniform size bitmaps, see below). (Personally I don't >like the terms like INNERBOUNDINGBOX or OUTERBOUNDINGBOX.) > Since all the glyphs are of uniform size, there is no need to have two bounding boxes. Since BOUNDINGBOX as in BDF may contain inter-glyph spacing, its width (height) is not necessarily the same as that of the actual bitmap. For example, for a 16x16 bitmap, the BOUNDINGBOX can be 16x16 or 18x20. However, BOUNDINGBOX information is useful when two HBF files (one describing ASCII fonts perhaps) are considered together to decide the placement with respect to the common base line. Hence, we do need both BOUNDINGBOX and BITMAPSIZE. For those who are interested in comparison with BDF, the correspondence of the information associated with the proposed BITMAPSIZE is acutally encoded on a per character basis in BDF (to allow variable pitch fonts). >The pseudo API (I am lazy to create new names, so use C++ syntax and its >overloading notation here): > >(1) void HBF_GetBitmapSize(HBF_Handle, int& width, int& height); > >(2) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&); > >For HBF n.0, if it's decided to support different size bitmap segments, >a new API could simply be added: > >(3) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&, int& width, > int& height); > >In this version of the library, HBF_GetBitmapSize returns the maximum >width and height of all the bitmaps; HBF_GetBitmapSize(3) returns >additional info for individual bitmap; and HBF_GetBitmap(2) automatically >pads the bitmap to the width and height returned by (1). > >-Ricky The meaning of the API is very clear. I can easily see how programs, such as hz2ps, can adapt to HBF with a change of a few lines. As for (3), I don't need it now, but I know it can added easily to HBF in the future if desired. -Fung From lee@fritter.Stanford.EDU Thu Feb 25 13:19:26 1993 Return-Path: Date: Thu, 25 Feb 93 11:14:24 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Thu, 25 Feb 93 03:23:03 -0500 <9302250823.AA17484@fredholm.math.psu.edu> Subject: Bounding Box versus actual Bitmap dimensions Status: O >From: Stephen G Simpson >Date: Thu, 25 Feb 93 03:23:03 -0500 > >In choosing keywords for font attributes, we should be careful not to >conflict with the BDF standard. In particular, FONTBOUNDINGBOX in HBF >should denote exactly the same attributes as in BDF. If we convert an >HBF file to a BDF file (using R. Yeung's proposed hbf2bdf program), >the FONTBOUNDINGBOX lines in the two files should be identical. > >As a general rule governing the relationship between HBF and BDF, I >would propose that an HBF font may optionally include all the >information needed to construct a BDF font, and that this information >should be specified by exactly the same keywords as in the BDF file. >Any additional HBF information should be specified by new keywords >which are unique to HBF. (Maybe these new keywords should all begin >with the letters HBF, as in HBFINFO.) In this way, HBF will not >conflict with BDF. > >-- S. Simpson I agree with Stephen's general rule (which should be mentioned in some form in the HBF standard document), but not the particular keyword HBFINFO and its associated entries: it has two extra fields. Please see Ricky's proposal and my response. From lee@fritter.Stanford.EDU Thu Feb 25 13:46:24 1993 Return-Path: Date: Thu, 25 Feb 93 11:39:40 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: ZIKU24, CHBF and more Status: O >Date: Thu, 25 Feb 93 10:42 CST >From: CAI@neurophys.wisc.edu >X-Vms-To: IN%"soft-authors@ifcss.org" > >I think we should not make HBF too complicated at this stage. I agree with >mcpong that we shoul stick to the original order and should not worry about >ZIKU24 in BYX very much. Once a standard is set, the author of BYX may be >willing to change, it is not a difficult job and it does cost much anyway. >If he did not change, the users may complain to hi, or they can turn away, >for example, switch to NJSTAR. After we have tried the standard, and we >found there is indeed a need for another order, we can easily put it on >in the next version. But if we do it now, we are never going to have a nicc, >simple and clean standard. Yes, the "HINT" of the reason why BYX chose a different bitmap format (non-row-major) is perhaps best given by Jiang: >From jiang@ifcss.org Thu Feb 25 10:21:18 1993 >Received: by ifcss.org (4.1/IFCSS-Mailer) id AA18374; Thu, 25 Feb 93 12:19:17 CST >Date: Thu, 25 Feb 93 12:19:17 CST >From: jiang@ifcss.org (Yuan Jiang) > >Some software authors intentionally rearranged the format of the >font from CCDOS or other sources to avoid copyright complications. > >So, if fonts conform to a standard are widely available, it will >free a lot programmers energy in struggling with fonts and copyright >issues. It is one of the goals of HBF to minimize the copyright issues. I remember years ago when I could only distribute the source codes of hz2ps, but not any font files, hence render hz2ps useless for many people who could have used it. If something like HBF were available, I could at least supply the CCDOS, ETen and Macintosh HBF template files so that many more people could use hz2ps while I didn't have to worry about the copyright issues. Whether the users can use their purchased or licensed font files for other purposes are their own problems ! 8-) >For mcpong's proposed change of HBF to CHBF, it is not needed at all once >you specified what order you have used. If one did not bother to read >the standard, he is not going to use it anyway. Another reason for not using >CHBF is that most people may want to name the HBF file as *****.hbf but not >*****.chbf, which is not allowed on PC. CBF can be even worse, does C stand >for Chinese or Canonical as you intended to ? Agree. In fact, JIS (the 8-bit one) is so similar to 8-bit GB (or the other way around, since JIS came first), I bet that with minimal change (for kana), most Chinese software can easily display Japanese kanji given the right font files, which can definitely be handled elegantly by HBF. Hence, the letter 'H' for hanzi in HBF rather than 'C' for Chinese. By the way, hanzi/kanji is referred to as Han character in Unicode, so there is one more reason to use the letter 'H'. Who knows, if we design a good standard, perhaps HBF may be adopted for wider use and even will emerge as some sort of de facto (industry) standard. :-) -Fung From lee@fritter.Stanford.EDU Thu Feb 25 13:46:30 1993 Return-Path: Date: Thu, 25 Feb 93 11:38:54 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: ZIKU24, CHBF and more Status: O >Date: Thu, 25 Feb 93 10:42 CST >From: CAI@neurophys.wisc.edu >X-Vms-To: IN%"soft-authors@ifcss.org" > >I think we should not make HBF too complicated at this stage. I agree with >mcpong that we shoul stick to the original order and should not worry about >ZIKU24 in BYX very much. Once a standard is set, the author of BYX may be >willing to change, it is not a difficult job and it does cost much anyway. >If he did not change, the users may complain to hi, or they can turn away, >for example, switch to NJSTAR. After we have tried the standard, and we >found there is indeed a need for another order, we can easily put it on >in the next version. But if we do it now, we are never going to have a nicc, >simple and clean standard. Yes, the "HINT" of the reason why BYX chose a different bitmap format (non-row-major) is perhaps best given by Jiang: >From jiang@ifcss.org Thu Feb 25 10:21:18 1993 >Received: by ifcss.org (4.1/IFCSS-Mailer) id AA18374; Thu, 25 Feb 93 12:19:17 CST >Date: Thu, 25 Feb 93 12:19:17 CST >From: jiang@ifcss.org (Yuan Jiang) > >Some software authors intentionally rearranged the format of the >font from CCDOS or other sources to avoid copyright complications. > >So, if fonts conform to a standard are widely available, it will >free a lot programmers energy in struggling with fonts and copyright >issues. It is one of the goals of HBF to minimize the copyright issues. I remember years ago when I could only distribute the source codes of hz2ps, but not any font files, hence render hz2ps useless for many people who could have used it. If something like HBF were available, I could at least supply the CCDOS, ETen and Macintosh HBF template files so that many more people could use hz2ps while I didn't have to worry about the copyright issues. Whether the users can use their purchased or licensed font files for other purposes are their own problems ! 8-) >For mcpong's proposed change of HBF to CHBF, it is not needed at all once >you specified what order you have used. If one did not bother to read >the standard, he is not going to use it anyway. Another reason for not using >CHBF is that most people may want to name the HBF file as *****.hbf but not >*****.chbf, which is not allowed on PC. CBF can be even worse, does C stand >for Chinese or Canonical as you intended to ? Agree. In fact, JIS (the 8-bit one) is so similar to 8-bit GB (or the other way around, since JIS came first), I bet that with minimal change (for kana), most Chinese software can easily display Japanese kanji given the right font files, which can definitely be handled elegantly by HBF. Hence, the letter 'H' for hanzi in HBF rather than 'C' for Chinese. By the way, hanzi/kanji is referred to as Han character in Unicode, so there is one more reason to use the letter 'H'. Who knows, if we design a good standard, perhaps HBF may be adopted for wider use and even will emerge as some sort of de facto (industry) standard. :-) -Fung From simpson@math.psu.edu Thu Feb 25 14:36:44 1993 Return-Path: From: Stephen G Simpson Date: Thu, 25 Feb 93 15:28:49 -0500 To: soft-authors@ifcss.org Subject: BITMAPSIZE Status: O F. F. Lee writes > >BITMAPSIZE wid ht > > Since all the glyphs are of uniform size, there is no need to have > two bounding boxes. Since BOUNDINGBOX as in BDF may contain inter-glyph > spacing, its width (height) is not necessarily the same as that of the > actual bitmap. For example, for a 16x16 bitmap, the BOUNDINGBOX can be > 16x16 or 18x20. However, BOUNDINGBOX information is useful when > two HBF files (one describing ASCII fonts perhaps) are considered together > to decide the placement with respect to the common base line. > Hence, we do need both BOUNDINGBOX and BITMAPSIZE. If we are going to have both BDF-style bounding box information and BITMAPSIZE (and I also in favor of this), then it seems to me we also need two additional attributes, telling how the bitmap should be placed within the bounding box. So we really need BITMAPSIZE wid ht bitmapxdisp bitmapydisp or to use my notation from an earlier posting HBINFO bw bh bxd byd Here bitmapxdisp and bitmapydisp (or, bxd and byd) tell the coordinates of the lower left corner of the bitmap relative to the lower left corner of the bounding box. This information is not contained in the BDF bounding box information! As you pointed out, BDF supplies this information on a per character basis. HBF can specify it on a per font basis, but we do need to specify it. From yawei@bronze.ucs.indiana.edu Thu Feb 25 15:03:15 1993 Return-Path: Date: Thu, 25 Feb 1993 15:57:03 -0500 From: ~{QG9p~} To: lee@fritter.stanford.edu, soft-authors@ifcss.org Subject: Re: ZIKU24, CHBF and more Status: O >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. Ya-Gui Wei From lee@fritter.Stanford.EDU Thu Feb 25 15:09:57 1993 Return-Path: Date: Thu, 25 Feb 93 13:05:16 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Updated examples of HBF (header) files Status: O Following is an updated sample file. Please correct me if they do not conform to the "current" version of HBF. It shows only all the compulsory entries (with COMMENTs). -Fung ========================================= An updated sample HBF file (Feb 25, 1993) ========================================= HBFVERSION 1.0 ENCODING "BIG5 ETen v2.0" FONT ETKai24 COMMENT COMMENT An equivalent full X11R5 XLFD conforming font name is COMMENT -eten-kai-medium-r-normal-fan-24-240-80-80-c-240-eten.big5-0 COMMENT FONTBOUNDINGBOX 24 24 0 -2 STARTPROPERTIES 4 FAMILY_NAME "Kai" ADD_STYLE_NAME "Fan" DEFAULT_CHAR 0xA140 COPYRIGHT "Public Domain HBF file" ENDPROPERTIES NOTICE "The bitmap font files should conform to the format of ETen v2.0" COMMENT Users should observe the copyright of the individual bitmap font files. COMMENT COMMENT [[ It is absolutely important that there is no ambuguity about COMMENT the copyright of this header file and those of bitmap files. -FFL]] COMMENT CHARS 13867 BITMAPSIZE 24 24 COMMNET If S. Simpson is right, this would be COMMENT BITMAPSIZE 24 24 0 -2 STARTBYTE2_RANGES 2 BYTE2_RANGE 0x40-0x7E BYTE2_RANGE 0xA1-0xFE ENDBYTE2_RANGES STARTSEGMENTS 4 SEGMENT 0xA140-0xA3BF "SPCFONT.24" 0 SEGMENT 0xA440-0xC67E "STDFONT.24K" 0 SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 0 SEGMENT 0xC940-0xF9FE "STDFONT.24K" 388872 ENDSEGMENTS ENDFONT ------------------------------end---------------------------------------- From lee@fritter.Stanford.EDU Thu Feb 25 15:31:15 1993 Return-Path: Date: Thu, 25 Feb 93 13:26:24 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: BITMAPSIZE Status: O >From: Stephen G Simpson >Date: Thu, 25 Feb 93 15:28:49 -0500 > >Here bitmapxdisp and bitmapydisp (or, bxd and byd) tell the >coordinates of the lower left corner of the bitmap relative to the >lower left corner of the bounding box. This information is not >contained in the BDF bounding box information! As you pointed out, >BDF supplies this information on a per character basis. HBF can >specify it on a per font basis, but we do need to specify it. The information is indeed contained in the BDF bounding box fields. BDF has to supply the info on per char basis because it may be different char by char, but for hanzi, the info is the same for all chars. Given FONTBOUNDINGBOX bwidth bheight bxdisp bydisp, BITMAPSIZE width height the lower-left corner of a width x height bitmap should be placed at a displacement of (bxdisp, bydisp) from the current "point", which is a point located on the "baseline". Aftering "printing" of this char, the current "point" is now moved by a displacement of (bwidth, 0). To avoid overlapping lines, the distance between two adjacent lines should be "bheight" pixels, if a pixel is the measuring unit. (constraints: bwidth >= width, bheight >= height) It seems to me this is completely sufficient. I may be wrong though. If we really need two sets of xdisp, ydisp, please give a scenario when they are necessary. -Fung From simpson@math.psu.edu Thu Feb 25 21:21:03 1993 Return-Path: From: Stephen G Simpson Date: Thu, 25 Feb 93 22:10:41 -0500 To: soft-authors@ifcss.org Subject: FONTBOUNDINGBOX displacement vs. BITMAPSIZE displacement Status: O F. F. Lee writes > Given > FONTBOUNDINGBOX bwidth bheight bxdisp bydisp, > BITMAPSIZE width height > the lower-left corner of a width x height bitmap should be placed at > a displacement of (bxdisp, bydisp) from the current "point", > which is a point located on the "baseline". > ... > It seems to me this is completely sufficient. > I may be wrong though. If we really need two sets of xdisp, ydisp, > please give a scenario when they are necessary. This issue is more complicated than I thought. And I also am open to correction, especially since I am not an expert on BDF. (I have studied the BDF and XLFD documents but not everything in them makes sense to me, and I haven't done any X window programming.) Anyway, here is the scenario. Imagine you are M. C. Pong and you want to use two available sets of bitmaps, 15x15 traditional characters (the ET font) and 16x16 simplified characters (the CCLIB font) in a certain application. Your application is going to display bitmaps from both fonts in close proximity, on the same line. In writing the application, you find it convenient to pretend that all of the bitmaps are 16x16 and for aesthetic reasons you want to place them both at the same displacement relative to the baseline, namely 2 pixels below the baseline. You want to pretend both fonts are 16x16 because that way, if you later get hold of a true 16x16 traditional character font, you won't have to rewrite your application. So, for both of your fonts, the bounding box information is FONTBOUNDINGBOX 16 16 0 -2 However, internally, the 15x15 bitmaps are to be padded to 16x16. There are four different ways to do the padding: top and right, top and left, bottom and right, bottom and left. You make a choice, and you want your HBF header file to reflect this choice. What parameters do you use to do it? My view is that you need two extra parameters, whose four possible sets of values in this case would be 0 and 0, 0 and 1, 1 and 0, 1 and 1 respectively. Actually it depends on exactly how we want to define these parameters -- maybe the four sets of values would be 0 and -2, 0 and -1, 1 and -2, 1 and -1 respectively. In any case, I would propose four different possibilities for the BITMAPSIZE line, something like BITMAPSIZE 15 15 0 -2 BITMAPSIZE 15 15 1 -2 BITMAPSIZE 15 15 0 -1 BITMAPSIZE 15 15 1 -1 The same problem comes up and is solved in the same way in the BDF format, but on a character by character basis. In BDF there is a line FONTBOUNDINGBOX width height xdisp ydisp exactly as above, and in addition each character has a line which looks like BBX BBw BBh BBox BBoy (BBX is the keyword, the other 4 are numerical parameters). The BBox and BBoy parameters specify "the x and y displacement of the lower left corner from the origin of the character" (quoting from the BDF document). The meaning of BBox and BBoy is illustrated by examples in the BDF document. For FONTBOUNDINGBOX, xdisp and ydisp are said to express "the x and y displacement of the lower left corner from the origin." (I find this somewhat hard to understand, but I take it to mean that xdisp and ydisp give the displacent of the lower left corner of the bounding box from the origin, while BBox and BBoy give the displacement of the lower left corner of the character from the origin.) Let me ask you, how would you handle this situation? Maybe you are going to say something like FONTBOUNDINGBOX 16 15 0 -2 FONTBOUNDINGBOX 16 15 1 -2 FONTBOUNDINGBOX 16 15 0 -1 FONTBOUNDINGBOX 16 15 1 -1 The trouble is that this is not the same as the bounding box of the CCLIB font, even though you want both fonts to look the same to your application. I hope this makes sense. Maybe I am completely misunderstanding something about BDF, because I know for a while I was confusing the FONTBOUNDINGBOX information with FONT_ASCENT and FONT_DESCENT. Anyway, if this doesn't seem right to you, I give up and withdraw my suggestion for two extra parameters. From mcpong@uxmail.ust.hk Thu Feb 25 22:15:02 1993 Return-Path: Date: Fri, 26 Feb 93 12:06:04 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: BITMAP & DISPLAY BOUNDINGBOX Status: O After reading yesterday's responses, I actually start to give up pushing for distinction of BITMAP & DISPLAY BOUNDINGBOXes in HBF Standard 1.0 & hope that Standard 1.0 will come out, be implemented and approved sooner. But after reading Simpson's mail, who seems to now supporting the distinction (Thanks), I can't stop typing this mail. :-) :-) I intend not to use the terms FONTBOUNDINGBOX or HBFINFO or BBX first to avoid confusion. Conceptually, for hanzi, per glyph BITMAPBOUNDINGBOX is the same as the BOUNDINGBOX for the whole font since it consists of fixed width glyphs. The DISPLAYBOUNDINGBOX is what we want a glyph to be placed on the screen or printed by the printer. (Thus the use of DISPLAY -- in previous mail I used OUTBOUNDINGBOX or OUTPUTBOUNDINGBOX which is not so clear.) -------------------------------------------------------------------- To display a glyph bitmap in a rectangular area with size larger than the bitmap size, information of both BOUNDINGBOXes are necessary, where a BOUNDINGBOX is (w,h,xd,yd). Usually, we need to display hanzi with ASCII char, thus the baseline of a line of glyphs is usually not the lower left corner of a glyph, to take care of the descent of ASCII glyphs like "j", "Q". The ascent and descent are measured from the baseline, which is like the x-axis. The BBX properties in X11R5 BDF is per-glyph-boundingbox, which is equivalent to the BITMAPBOUNDINGBOX for hanzi bitmap. |<--- width --->| - ----------------- - ^ | | | ^ | | | | | ascent | | | | | | | | height | | | | | baseline ---->- ----O------------ | point "O" = Origin | | | | | descent | | | | descent = yDisplacement v | | | v - ----------------- - |<--| xDisplacement ygz@cs.purdue.edu looked into the X11R5 BDF files yesterday and found: > FONTBOUNDINGBOX is a rectangle that holds all BBX. > > Note that different BBX may have different origin, > for example, BBX1 is 4,4,1,1, i.e. from (1,1) to (5,5) > and BBX2 is 3,3,-1,-1, i.e. from (-1,-1) to (2,2) > then the FONTBBX is at least 6,6,-1,-1, i.e., from (-1,-1) to (5,5). > > In most case, FONTBOUNDINGBOX is the minimal rectangle that holds > all BBX. > > I try it on all *.bdf come with X11R5, there is only a few exceptions. > > > Can a glyph be shown (partially) outside FONTBOUNDINGBOX? > > Usually no. But there are a few that I don't understand. > e.g. jiskan16.bdf: BBX for each kanji is 16,16,0,-2, > but the FONTBOUNDINGBOX is 16,16,0,2. I don't know jiskan16.bdf is in error or not; may be its FONTBOUNDINGBOX should be 16,16,0,-2 as well. Once during a conversion of a **fixed-width** bitmap file to a BDF, I hadn't made BBX & FONTBOUNDINGBOX consistent, and the font is still usable with an ASCII font in X11R5. So, maybe nobody else cares further. (Is it also the case for jiskan16.bdf ??) I discovered the inconsistency only when I tried to convert 2 **fixed-width** bitmap files to BDFs and tried to display characters from the two fonts together, and I found that the bottoms of the glyphs of the two fonts didn't align. Anyway, that seems to be a side issue. [[?]] ----------------------------------------------------------------- I would say that BDF FONTBOUNDINGBOX is the BITMAPBOUNDINGBOX of a fixed-wideth hanzi glyph (== that of a hanzi font). For variable-width font, per-glyph information is used to show a glyph A, say at its origin OA, within the FONTBOUNDINGBOX. ^^^^^^^^^^^^^^^^^^^^^^^^^^ The FONTBOUNDINGBOX can be larger than the per-glyph boundingbox; i.e. larger than BBX. The origin of next glyph B in the line of text will be shown using origin OB.x = OA.x + FONTBOUNDINGBOX.w (The relative origins OA & OB are all along the same baseline, if A & B are on the same line of text.) ----------------------------------------------------------------- In HBF file, the BITMAPBOUNDINGBOX should be the same for each glyph and is the same as the HBF. It's exactly the meaning for X11R5 BDF FONTBOUNDINGBOX for each individual font. ^^^ ^^^^^^^^^^^^^^^ To display two fonts with different FONTBOUNDINGBOXes, the application has to take care of the difference. When I proposed DISPLAYBOUNDINGBOX (or OUTPUTBOUNDINGBOX) previously, I try to cope with the problem of different BITMAPBOUNDINGBOXes for different HBF with a common-to-all-font DISPLAYBOUNDINGBOX in mind; and thus saying DISPLAYBOUNDINGBOX should be optional in HBF while BITMAPBOUNDINGBOX (== FONTBOUNDINGBOX) should be compulsory. Now, I think that the DISPLAYBOUNDINGBOX should be kept away from the HBF description, as it is not the description of the hanzi bitmap font. In short: Let the application deal with the DISPLAYBOUNDINGBOX problem. ----------------------------------------------------------------------- For my application using a mix of 16x16 and 15x15 (actually 16x15) bitmap fonts, I have to deal with it at the application level; which seems fair enough. Hope this can make the points clear. I shall update draft v0.1 to v0.2; with only FONTBOUNDINGBOX property (for X11R5 BDF conformance), and no DISPLAYBOUNDINGBOX property. When more needs arise from more applications later, we may re-consider the DISPLAYBOUNDINGBOX issue in HBF Standard vN.0 Please mail any objection ASAP :-) mcpong From lee@fritter.Stanford.EDU Fri Feb 26 16:51:09 1993 Return-Path: Date: Fri, 26 Feb 93 14:41:16 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: FONTBOUNDINGBOX and BITMAPBOUNDINGBOX Status: O Thanks for the posting of M.C Pong and S. Simpson about the bounding boxes of BDF. Rather than doing a point-by-point comparison of all these proposals about the bounding boxes, let's begin from first principle. (yes, I have strong confidence that BDF is always a good starting point.) To follow the philosophy of HBF as a efficient reduction of BDF that facilitate perfect translation from HBF to BDF, let's have two kinds of bounding boxes corresponding to FONTBOUNDINGBOX and BBX. The syntax and semantics of FONTBOUNDINGBOX can be exactly copied, including the fact the width and height of FONTBOUNDINGBOX can be larger than those of the hanzi bitmaps (and other possible ambuguity :-) Since each entry of BBX for a hanzi font is supposed to be the same, let's extract the "constant" and call it BITMAPBOUNDINGBOX instead of BBX to avoid the confusion. Basically, the really useful stuff for most applications is the bwidth and bheight fields of BITMAPBOUNDINGBOX. FONTBOUNDINGBOX is there for compatibility with BDF and allowing for inter-glyph spacing information. A. 16x16 font ------------- HBF1: FONTBOUNDINGBOX 16 16 0 -2 BITMAPBOUNDINGBOX 16 16 0 -2 HBF2: (to allow for inter-glyph spacing of 2 pixels) FONTBOUNDINGBOX 18 16 0 -2 BITMAPBOUNDINGBOX 16 16 0 -2 B. 16x15 font ------------- HBF3: (to be aligned at the top with HBF1) FONTBOUNDINGBOX 16 16 0 -2 BITMAPBOUNDINGBOX 16 15 0 -1 HBF4: (to be aligned at the top with HBF2) FONTBOUNDINGBOX 18 16 0 -2 BITMAPBOUNDINGBOX 16 15 0 -1 HBF5: (to be aligned at the bottom with HBF1) FONTBOUNDINGBOX 16 16 0 -2 BITMAPBOUNDINGBOX 16 15 0 -2 As for API, I like Ricky's proposal: >The pseudo API (I am lazy to create new names, so use C++ syntax and its >overloading notation here): > >(1) void HBF_GetBitmapSize(HBF_Handle, int& width, int& height); > >(2) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&); > but need to update to (3) void HBF_GetBitmapBoundingBox(HBF_Handle, int& width, int& height, int& xdisp, int& ydisp); (4) void HBF_GetFontBoundingBox(HBF_Handle, int& width, int& height, int& xdisp, int& ydisp); The width and height returned from HBF_GetBitmapBoundingBox() or HBF_GetBitmapSize() will be the TRUE bitmap dimensions, with the convention that the raw bitmap bytes are stored so that each row of the bitmap is stored in Ceiling(width/8) bytes (see draft 0.1). It is up to the applications to decide whether it can handle the 16x15 or even 12x14 bitmap returned by HBF_GetBitmap(). Providing services for transformations of the aboved returned bitmaps may be desirable for some applications, because they probably will have less work to do, but at the cost of making HBF more complicated than necessary. Therefore, I strongly object to providing these extra services in HBF v1.0 API. -Fung From mcpong@uxmail.ust.hk Fri Feb 26 19:47:00 1993 Return-Path: Date: Sat, 27 Feb 93 09:35:36 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: BITMAPBOUNDINGBOX & API Cc: mcpong@uxmail.ust.hk Status: O > Date: Fri, 26 Feb 93 14:41:16 -0800 > From: lee@fritter.stanford.edu (Fung Fung Lee) > Subject: FONTBOUNDINGBOX and BITMAPBOUNDINGBOX > > Since each entry of BBX for a hanzi font is supposed to be the same, > let's extract the "constant" and call it > BITMAPBOUNDINGBOX instead of BBX to avoid the confusion. > Basically, the really useful stuff for most applications > is the bwidth and bheight fields of BITMAPBOUNDINGBOX. > FONTBOUNDINGBOX is there for compatibility with BDF and allowing for > inter-glyph spacing information. > > > A. 16x16 font > ------------- > HBF1: > FONTBOUNDINGBOX 16 16 0 -2 > BITMAPBOUNDINGBOX 16 16 0 -2 > > HBF2: (to allow for inter-glyph spacing of 2 pixels) > FONTBOUNDINGBOX 18 16 0 -2 > BITMAPBOUNDINGBOX 16 16 0 -2 > > > B. 16x15 font > ------------- > HBF3: (to be aligned at the top with HBF1) > FONTBOUNDINGBOX 16 16 0 -2 > BITMAPBOUNDINGBOX 16 15 0 -1 > > HBF4: (to be aligned at the top with HBF2) > FONTBOUNDINGBOX 18 16 0 -2 > BITMAPBOUNDINGBOX 16 15 0 -1 > > HBF5: (to be aligned at the bottom with HBF1) > FONTBOUNDINGBOX 16 16 0 -2 > BITMAPBOUNDINGBOX 16 15 0 -2 [[ I support that we should precede all HBF related names with "HBF_". ]] I can add HBF_BITMAPBOUNDINGBOX property to draft v0.2. The consequence will be more complicated implementation for HBF_GetBitmap(), i.e. has to make sure the bitmap is returned according to FONTBOUNDINGBOX. I suppose what we mean is to return the bitmap of size FONTBOUNDINGBOX, not HBF_BITMAPBOUNDINGBOX; agree? (No matter FONTBOUNDINGBOX is HBF_BITMAPBOUNDINGBOX or not, the implementation still has to check the case when they are unequal and pad the difference of the 2 bounding-boxes when necessary.) Compare 2 cases: (1) with HBF_BITMAPBOUNDINGBOX: PtrHBF_Octet HBF_GetBitmap( IN HBF_Handle handle, IN HBF_hzcode hanziCode ); /* Get the bitmap of size FONTBOUNDINGBOX for the given hanzi code. * The bitmap of the given hanzi will be placed properly in the * FONTBOUNDINGBOX according to the properties of FONTBOUNDINGBOX * and HBF_BITMAPBOUNDINGBOX. * * 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. */ /************************************************************/ (2) without HBF_BITMAPBOUNDINGBOX: (The concept is not mentioned as all; i.e. FONTBOUNDINGBOX is size of glyph bitmap.) 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. */ /************************************************************/ A poll of opinions to all readers: like to have HBF_BITMAPBOUNDINGBOX or not in HBF Standard v1.0? > As for API, I like Ricky's proposal: > > >The pseudo API (I am lazy to create new names, so use C++ syntax and its > >overloading notation here): > > > >(1) void HBF_GetBitmapSize(HBF_Handle, int& width, int& height); > > > >(2) HBF_GetBitmap(HBF_Handle, u_int16 code, HBF_BITMAP&); > > > but need to update to > (3) void HBF_GetBitmapBoundingBox(HBF_Handle, int& width, int& height, > int& xdisp, int& ydisp); > > (4) void HBF_GetFontBoundingBox(HBF_Handle, int& width, int& height, > int& xdisp, int& ydisp); > > The width and height returned from HBF_GetBitmapBoundingBox() or > HBF_GetBitmapSize() will be the TRUE bitmap dimensions, with > the convention that the raw bitmap bytes are stored so that > each row of the bitmap is stored in Ceiling(width/8) bytes (see draft 0.1). > It is up to the applications to decide whether it can handle the > 16x15 or even 12x14 bitmap returned by HBF_GetBitmap(). Agree. > Providing services for transformations of the aboved returned bitmaps > may be desirable for some applications, because they probably will have > less work to do, but at the cost of making HBF more complicated than > necessary. Therefore, I strongly object to providing these extra services > in HBF v1.0 API. There are strong reasons for some programs (e.g. printing programs) to use byte-sequence of sideway bitmap. Bitmap files according to HBF v1.0 is still for upright bitmap. We can specify two levels of API, one is the minimum set which only takes care of upright bitmaps. An extended level of API routines include (may not be released with the sample implementation of HBF v1.0): (The following routines has NOT be updated to take care of HBF_BITMAPBOUNDINGBOX. The bitmap should be rotated before putting into FONTBOUNDINGBOX.) (If no HBF_BITMAPBOUNDINGBOX in HBF v1.0, no need to update; save effort :-) 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. */ /************************************************************/ mcpong From simpson@math.psu.edu Sat Feb 27 16:56:14 1993 Return-Path: From: Stephen G Simpson Date: Sat, 27 Feb 93 17:48:46 -0500 To: soft-authors@ifcss.org Subject: BITMAPBOUNDINGBOX (renamed HBFBBX ?) vs. FONTBOUNDINGBOX Status: O The most recent postings by F. F. Lee and M. C. Pong helped to clarify the issue in my mind. I now favor F. F. Lee's most recent proposal, which does almost all of what we want and has the virtue of simplicity ("back to basics"). Here is F. F. Lee's proposal, with my comments: > To follow the philosophy of HBF as a efficient reduction of BDF > that facilitate perfect translation from HBF to BDF, let's have > two kinds of bounding boxes corresponding to FONTBOUNDINGBOX and BBX. > The syntax and semantics of FONTBOUNDINGBOX can be exactly copied, > ... > Since each entry of BBX for a hanzi font is supposed to be the same, > let's extract the "constant" and call it > BITMAPBOUNDINGBOX instead of BBX to avoid the confusion. [ Or, how about calling it something like HBFBBX or HBF_BBX? We can't call it BBX, because that would conflict with the BDF usage. However, it conveys exactly the same information as BBX -- the only difference is that it is uniform over all bitmaps in the font, taking advantage of the uniform bitmap sizes in HBF fonts. Hence the name HBFBBX. ] > Basically, the really useful stuff for most applications > is the bwidth and bheight fields of BITMAPBOUNDINGBOX. > FONTBOUNDINGBOX is there for compatibility with BDF and allowing for > inter-glyph spacing information. [ This clarifies the issue for me. Not being an X window programmer, I wasn't sure exactly how X applications use the FONTBOUNDINGBOX and BBX information. F. F. Lee seems to be saying that, usually, X applications ignore FONTBOUNDINGBOX because they are only interested in true bitmap dimensions, as expressed in BBX. Therefore, we should provide this information in HBFBBX (similar to BBX), with the understanding that most applications will be most interested in this. In addition to HBFBBX, we should of course make provision FONTBOUNDINGBOX and many other BDF keywords and parameters, for compatibility with BDF. Question: Should FONTBOUNDINGBOX be required or optional? In other words, should FONTBOUNDINGBOX be part of what R. Yeung called the "simplified" HBF specification, or should it be included only in the "fully specified" HBF specification? Since according to the current proposal, the HBF 1.0 API is returning only HBFBBX information, it seems to me that FONTBOUNDINGBOX can be made optional, at least for the time being. ] > ... > The width and height returned from HBF_GetBitmapBoundingBox() or > HBF_GetBitmapSize() will be the TRUE bitmap dimensions, with > the convention that the raw bitmap bytes are stored so that > each row of the bitmap is stored in Ceiling(width/8) bytes (see draft 0.1). > It is up to the applications to decide whether it can handle the > 16x15 or even 12x14 bitmap returned by HBF_GetBitmap(). > > Providing services for transformations of the aboved returned bitmaps > may be desirable for some applications, because they probably will have > less work to do, but at the cost of making HBF more complicated than > necessary. Therefore, I strongly object to providing these extra services > in HBF v1.0 API. [ I take this to mean that the HBF 1.0 API should not provide the service of padding bitmaps. The HBF 1.0 API should return only the actual bitmaps with their actual bitmap sizes (as specfied in HBFBBX). Padding is to be left to the application. This seems like a practical approach and I now agree with it, despite my earlier argument in favor of padding services. Similarly, we could define services for rotating bitmaps (as M. C. Pong has already done), but not provide them in the HBF 1.0 API, perhaps reserving them for future versions. ] From lee@fritter.Stanford.EDU Sat Feb 27 18:34:17 1993 Return-Path: Date: Sat, 27 Feb 93 16:28:54 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: BITMAPBOUNDINGBOX (renamed HBFBBX ?) vs. FONTBOUNDINGBOX Status: O >From: Stephen G Simpson >Date: Sat, 27 Feb 93 17:48:46 -0500 > >The most recent postings by F. F. Lee and M. C. Pong helped to clarify >the issue in my mind. I now favor F. F. Lee's most recent proposal, >which does almost all of what we want and has the virtue of simplicity >("back to basics"). > ... 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. >[ Or, how about calling it something like HBFBBX or HBF_BBX? We can't >call it BBX, because that would conflict with the BDF usage. However, >it conveys exactly the same information as BBX -- the only difference >is that it is uniform over all bitmaps in the font, taking advantage >of the uniform bitmap sizes in HBF fonts. Hence the name HBFBBX. ] Currently I don't have strong preference for either HBF_BBX, HBFBBX or BITMAPBOUNDINGBOX. Once this bounding box issue is settled, we can come up with a set of new names invented for HBF that are (more?) consistent in naming convention. :-) >> Basically, the really useful stuff for most applications >> is the bwidth and bheight fields of BITMAPBOUNDINGBOX. >> FONTBOUNDINGBOX is there for compatibility with BDF and allowing for >> inter-glyph spacing information. > >[ This clarifies the issue for me. Not being an X window programmer, >I wasn't sure exactly how X applications use the FONTBOUNDINGBOX and >BBX information. F. F. Lee seems to be saying that, usually, X >applications ignore FONTBOUNDINGBOX because they are only interested >in true bitmap dimensions, as expressed in BBX. Therefore, we should >provide this information in HBFBBX (similar to BBX), with the >understanding that most applications will be most interested in this. I didn't say X applications ignore the information in FONTBOUNDINGBOX. Let me clarify. What I meant is that most existing Chinese freeware applications (yes, those written by the authors in this mailing list!) are most concerned with bitmap size information. The information encoded in FONTBOUNDINGBOX is either implied (say, FONTBOUNDINGBOX size is the same as BBX size) or specified separately (as by options in hz2ps). FONTBOUNDINGBOX provides yet another (more standard?) way to specify such information, which the applications may choose to ignore or override. Often X applications do not see the FONTBOUNDINGBOX directly, because they are shielded by the X font server, which provides services such as DrawText16() (e.g. see Ricky Yeung's xhzview()) The font / display server needs the information in FONTBOUNDINGBOX to guide the drawing of the bitmaps. >In addition to HBFBBX, we should of course make provision >FONTBOUNDINGBOX and many other BDF keywords and parameters, for >compatibility with BDF. > Yes. One simple way is to provide a HBF_GetProperty(char * keyword) routine to return the string associated with the keyword. For most (all?) optional HBF entries, the HBF library basically provides an associative search function. (See Ricky Yeung's previous suggestion.) This way, the applications can read everything in the optional entries without bothering HBF library to understand the meaning; the routines just pass the information blindly. >Question: Should FONTBOUNDINGBOX be required or optional? In other >words, should FONTBOUNDINGBOX be part of what R. Yeung called the >"simplified" HBF specification, or should it be included only in the >"fully specified" HBF specification? FONTBOUNDINGBOX should always be required. >Since according to the current proposal, the HBF 1.0 API is returning >only HBFBBX information, it seems to me that FONTBOUNDINGBOX can be >made optional, at least for the time being. ] As suggested in my last message, we can add one more call to get FONTBOUNDINGBOX information. >> ... >> The width and height returned from HBF_GetBitmapBoundingBox() or >> HBF_GetBitmapSize() will be the TRUE bitmap dimensions, with >> the convention that the raw bitmap bytes are stored so that >> each row of the bitmap is stored in Ceiling(width/8) bytes (see draft 0.1). >> It is up to the applications to decide whether it can handle the >> 16x15 or even 12x14 bitmap returned by HBF_GetBitmap(). >> >> Providing services for transformations of the aboved returned bitmaps >> may be desirable for some applications, because they probably will have >> less work to do, but at the cost of making HBF more complicated than >> necessary. Therefore, I strongly object to providing these extra services >> in HBF v1.0 API. > >[ I take this to mean that the HBF 1.0 API should not provide the >service of padding bitmaps. The HBF 1.0 API should return only the >actual bitmaps with their actual bitmap sizes (as specfied in HBFBBX). >Padding is to be left to the application. This seems like a practical >approach and I now agree with it, despite my earlier argument in favor >of padding services. Similarly, we could define services for rotating >bitmaps (as M. C. Pong has already done), but not provide them in the >HBF 1.0 API, perhaps reserving them for future versions. ] Yes, services such as rotating and padding bitmaps can be built on top of HBF 1.0 API. Don't include them in the API. I don't want HBF library to turn out to be a full-blown font server. It is easy to envision that one day HBF may become a standard way in X to store hanzi bitmap fonts, in parallel with BDF, such that the font server can understand HBF as well as BDF. (HBF will not replace BDF, but it will be as expressive as BDF when it comes to hanzi.) Hence, bundling too much services with HBF is not necessarily a good idea. (as it may need to unnecessary redundancy, and worse, inconsistency, so it is safer to stick the the basics.) As I see it, HBF library routines should correspond to those low level routines in X server which reads BDF and its derivatives (e.g. .pcf files). -Fung From lee@fritter.Stanford.EDU Sat Feb 27 18:58:12 1993 Return-Path: Date: Sat, 27 Feb 93 16:52:25 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Dr. PONG Man Chi's message of Sat, 27 Feb 93 09:35:36 HKT <9302270135.AA11242@uxmail.ust.hk> Subject: BITMAPBOUNDINGBOX & API Status: O >Date: Sat, 27 Feb 93 09:35:36 HKT >From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) >> Providing services for transformations of the aboved returned bitmaps >> may be desirable for some applications, because they probably will have >> less work to do, but at the cost of making HBF more complicated than >> necessary. Therefore, I strongly object to providing these extra services >> in HBF v1.0 API. > >There are strong reasons for some programs (e.g. printing programs) >to use byte-sequence of sideway bitmap. >Bitmap files according to HBF v1.0 is still for upright bitmap. >We can specify two levels of API, one is the minimum set which >only takes care of upright bitmaps. >An extended level of API routines include (may not be released with >the sample implementation of HBF v1.0): For binary images, there are at least 8 ways to desribe them "naturally": the cross-products: [scanning top-bottom] [scanning left-right] [1 is black, 0 is white] [ ] x [ ] x [ ] [scanning bottom-top] [scanning right-left] [0 is black, 1 is white] Different applications may choose to use any one of these formats. TIFF was an effort for unification of these formats (with additional properties). But look at how complicated TIFF is !! 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? How fast is the printer compared with the CPU which can do the bitmap rotation? Everything can be written in assembly, but is it really a good idea to write in assembly these days with optimizing compilers and strong emphasis in software portability? There are many ways to speed things up. Here's one way (not necessarily my preferred way though) for BYX-like program to handle it: * generating the "rotated bitmap file" from the upright one only when you need it, either store the bitmaps on disk, on memory or partly in memory, partly on disk. Once the upright bitmap is read in, it's up to the application to decide how to handle it. Conclusion: support only ONE standard bitmap order in HBF 1.0. Even if I am wrong, I don't see any harm in practice for supporting only one bitmap order. Future version may extend HBF to be as complicated as TIFF if it wants by simply adding more keywords overriding the default. -Fung