From cyl Thu Aug 18 23:51:19 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA21928; Thu, 18 Aug 94 23:51:19 CDT Date: Thu, 18 Aug 1994 23:51:18 -0500 (CDT) From: Nelson CHIN Subject: hi i'm back; hbf 1.1 To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO hi guys, i'm back from paraguay.. wading thru tons of email..:# i would like to see hbf version 1.1 out by a couple of weeks.. please comment on the current draft, see ftp://ifcss.org/software/info/HBFdraft/index.html or get ifcss.org:/software/info/HBFdraft/HBF.txt if you don't have www access. Nelson From simpson@math.psu.edu Fri Aug 19 18:15:34 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA14172; Fri, 19 Aug 94 18:15:34 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id TAA00909; Fri, 19 Aug 1994 19:12:59 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 19 Aug 1994 19:12:58 -0400 Date: Fri, 19 Aug 1994 19:12:58 -0400 Message-Id: <199408192312.TAA20203@boole.math.psu.edu> To: ccnet-l@uga.uga.edu, soft-authors@ifcss.org Subject: EHZ versus HZ+ In-Reply-To: <199408030330.XAA12834@leibniz.math.psu.edu> References: <199407152243.SAA26127@boole.math.psu.edu> <199408030330.XAA12834@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Ricky Yeung writes: > I'm not going to spend time to correct your misconception. I'd suggest > you pick up an intro compiler book and read the first several chapters > on parsing. Or, take a look at my implementation. If you still > can't figure it out, never mind. Well, if Ricky won't take the time to discuss this further, I guess that Ricky and I will just have to agree to disagree. For my part, I don't think I am suffering from any misconceptions regarding parsing or anything else. If Ricky thinks that I am suffering from misconceptions, he should spell out what misconceptions he is talking about. I stand by my claim (obvious to anyone who studies the specs) that EHZ's escape sequences are extremely complicated, much more complicated than HZ's or HZ+'s (or ISO-2022's for that matter), for all the reasons I mentioned: the 2-tier nature, the alleged need for look-ahead, the need for a default non-ASCII mode, etc. It is noteworthy that Ricky never replied to or commented on my posting of July 15 detailing these reasons. The other aspect of EHZ that I don't like is that EHZ's Big5 mapping scheme is to some extent arbitrary (by Fung's admission) and offers no apparent advantage over the simple, non-arbitrary Big5 mapping scheme used in Mule 1.0 and HZ+. So far as I can tell, the EHZ-Big5 mapping scheme was motivated by two considerations: (1) a desire for some not-fully-specified kind of compatibility with CNS, (2) a desire to be different from Mule and HZ+. Neither of these reasons seems sufficiently compelling. Having said all that, I nevertheless want to applaud Ricky's hard work in finally making an implementation of EHZ available. By the way, my implementation of HZ+ is very simple and has been available for several months at ftp.math.psu.edu, /pub/simpson/chinese/hzp. -- Steve From simpson@math.psu.edu Sat Aug 20 16:47:38 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA17514; Sat, 20 Aug 94 16:47:38 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id RAA02983; Sat, 20 Aug 1994 17:45:05 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Sat, 20 Aug 1994 17:45:03 -0400 Date: Sat, 20 Aug 1994 17:45:03 -0400 Message-Id: <199408202145.RAA21783@boole.math.psu.edu> To: ccnet-l%uga.BITNET@vm.psu.edu, soft-authors@ifcss.org Subject: EHZ versus HZ+, part 2 Reply-To: simpson@math.psu.edu Status: O In my previous posting I mentioned two objectionable aspects of EHZ and why I think HZ+ is better than EHZ in these two respects. Namely, (1) EHZ's escape sequences are much more complicated than HZ+'s, and (2) the EHZ-Big5 mapping scheme contains arbitrary features that make it more complicated than HZ+'s Big5 mapping scheme. I forgot to mention a third objectionable aspect of EHZ. Namely, EHZ as presented by its authors lacks a clear Big5 usage model. There are many possible methods of mapping Big5 into EHZ, and the authors of EHZ do not specify any one of these as being preferable. Instead, the authors tell Big5 users that they may want to translate EHZ-Big5 or EHZ-CNS or EHZ-GB or EHZ-JIS or any combination of these. This "neutral" or non-commital approach is bound to lead to confusion and errors. Ricky writes: > Can't you tell from the word "can" and "should"? Did he ever say "he > SHOULD post in mixed EHZ-CNS, EHZ-GB and EHZ-JIS"? Ricky is playing with words. Fung may not have used the word "should," but it's a fact that Fung seriously proposed an EHZ-CNS-GB-JIS mixture as a serious option for Big5 users. I find this aspect of EHZ unacceptable. Fortunately, this particular defect of EHZ should be easy to correct. In order to correct it, the authors of EHZ need merely add a few lines to the EHZ specification, recommending EHZ-Big5 and nothing else as the typical or preferred usage model for Big5 users. By the way, HZ+ does not suffer from any such defect. The HZ+ specification contains a very clear and simple usage model for Big5 users, namely the Big5 mapping scheme which is the heart of the specification. -- Steve From simpson@math.psu.edu Sun Aug 21 20:19:32 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA05120; Sun, 21 Aug 94 20:19:32 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id VAA08485; Sun, 21 Aug 1994 21:17:01 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Sun, 21 Aug 1994 21:16:59 -0400 Date: Sun, 21 Aug 1994 21:16:59 -0400 Message-Id: <199408220116.VAA23922@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l%uga.BITNET@vm.psu.edu Subject: HZ+ is now available at ifcss.org Reply-To: simpson@math.psu.edu Status: O A software package consisting of my HZ+ specification and related documents and conversion utilities is now available for anonymous FTP from ifcss.org. The Unix version, including source code, is at /software/unix/convert/hzp.tar.gz. The DOS version, including executables, is at /software/dos/convert/hzp.zip. Please test HZ+ and send me your comments. >From ifcss.org, /software/unix/convert/hzp.README: There is a need for a simple 7-bit representation of Big5 for use in e-mail, news postings, etc. I have proposed a scheme called HZ+. HZ+ is a 7-bit method of representing text that is a mixture of Big5, GB, and ASCII. HZ+ is a simple extension of the popular 7-bit HZ representation of mixed GB and ASCII. This archive contains documents and software related to HZ+. The latest version of this material should always be available for anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/hzp. Contents: README -- an information file hzp.doc -- my document describing HZ+ hz.doc -- an old document describing HZ etfonts.doc -- my old document describing Big5 howto.doc -- how to use my HZ+ filters big2hzp.c -- my filter to convert Big5 files to HZ+ files gb2hzp.c -- my filter to convert GB files to HZ+ files hzp2big.c -- my Big5 filter for HZ+ files hzp2gb.c -- my GB filter for HZ+ files Makefile -- makefile for my HZ+ filters -- Steve Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone +1 814 863-0775 Home phone +1 814 238-2274 E-mail simpson@math.psu.edu FAX +1 814 865-3735 World Wide Web http://www.math.psu.edu/simpson/ From cyl Tue Aug 30 18:04:33 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA03363; Tue, 30 Aug 94 18:04:33 CDT Date: Tue, 30 Aug 1994 18:04:31 -0500 (CDT) From: Nelson CHIN To: soft-authors@ifcss.org Subject: draft finalizing for HBF 1.1 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok, appended is the text draft for HBF 1.1, please review it.. the next draft will be finalised as HBF 1.1: also available at ftp://ifcss.org/software/info/HBFdraft/hbf.txt Hanzi Bitmap Font (HBF) File Format version 1.1 In a bitmap font for Chinese or a number of other languages, each character takes up the same amount of space, so such fonts are often provided as binary files containing only bitmaps. An HBF file is a human-readable text file describing a font of this type, and thus providing a uniform interface. Contents * HBF File Format * Code Schemes * Bounding Boxes * Bitmap File Format Appendices 1. Simple Example of an HBF File 2. Sample Full HBF File 3. History of this Document References 1. X Logical Font Description Conventions version 1.5 [ftp: dime.cs.umass.edu pub/rcf/exp/X11R6/xc/doc/hardcopy/XLFD/xlfd.PS.Z], X Consortium Standard, X11R6 (1988, 1994), by Jim Flowers of Digital Equipment Corporation. 2. Bitmap Distribution Format version 2.1 [ftp: dime.cs.umass.edu pub/rcf/exp/X11R6/xc/doc/hardcopy/BDF/bdf.PS.Z], X Consortium Standard, X11R6 (1984, 1987, 1988), by Adobe Systems, Inc. HBF File Format An HBF file is a US-ASCII-encoded, human-readable file describing a bitmap font in which all characters have identical dimensions and offsets. The character bitmaps are stored in separate binary files. The HBF file format is based on X11 BDF [2]. An HBF file consists of a series of variable-length lines (terminated by carriage-return and linefeed or just linefeed) each beginning with a keyword consisting of uppercase letters, digits and underscores. Many of these are borrowed from BDF 2.1, and have the same meaning as there. They are described here for completeness. Additional keywords consist of "HBF_" followed by one or more English words separated by underscores. In either case, tokens on each input line are separated by one or more spaces. Some definitions: * An unsigned integer may be in either decimal, hexadecimal, or octal format (BDF allows only decimal numbers). An octal integer is introduced by the prefix "0", a hexadecimal integer by the prefix "0x" (as in the C programming language). * The bytes of an n-byte code (usually n=2) are numbered 1 to n from most significant to least. Lines beginning with the keyword "COMMENT" may appear anywhere in the file, and are ignored. Other lines appear in the following order: 1. HBF_START_FONT formatVersion formatVersion: a token specifying the version of the HBF file format the file conforms to, so that backward compatibility can be supported even if a later version of this specification defines an altered format. The version described in this specification is 1.1. Note that the X11 BDF file keyword "STARTFONT" is not used. 2. HBF_CODE_SCHEME hanziCodeSchemeName hanziCodeSchemeName: one or more tokens representing the character code scheme used to index this font. See Code Schemes for possible values. 3. FONT fontName fontName: one or more tokens naming the font. Case distinctions should be ignored in font name matching. E.g. the following all refer to the same font, a 24x24 bitmap Kai style font from the ETen system: eb5-24k, Eb5-24K, EB5-24K. For full X compatability, the font name may conform to the X11R6 XLFD standard [1], as in the example full HBF file included as an appendix. 4. SIZE ptsize xres yres A BDF entry giving the point size of the font and the x- and y-resolutions of the device for which it was designed. These values will be unused unless BDF compatability is required. 5. HBF_BITMAP_BOUNDING_BOX w h xd yd w, h: width and height of the bounding-box of the glyph bitmap. xd, yd: the x- and y-displacement of the lower left corner of the glyph bitmap bounding-box from its origin. The HBF_BITMAP_BOUNDING_BOX value corresponds to the BDF 2.1 property "BBX" for each individual glyph in a font. Since HBF is tailored to fonts in which all glyphs have the same size, this information need only be specified once. 6. FONTBOUNDINGBOX w h xd yd w, h: width and height of the font bounding-box inside which the glyph bitmap of this HBF will be placed. xd, yd: the x- and y-displacement of the lower left corner of the font bounding-box from its origin. The relationship between HBF_BITMAP_BOUNDING_BOX and FONTBOUNDINGBOX is explained under Bounding Boxes. 7. STARTPROPERTIES p p: an unsigned integer, indicating the number of font properties that follow this line. (Note: in BDF 2.1, this whole properties section is optional.) There follow p lines, each comprising a property name and a value, which is either an integer or a quoted string. A quoted string is surrounded by double quotes ("), with any internal double quote represented by a pair of double quotes. These properties are defined in the XLFD standard [1]. Those particularly relevant to HBF are: + FAMILY_NAME quotedString This identifies the "family" of typeface designs that are all variations of one basic typographic style. E.g., "kai-ti" (meaning "kai style") is a common character font style. + ADD_STYLE_NAME quotedString This identifies additional typographic style information that is not captured by other fields but is needed to identify the particular font. It is not a typeface classification field and is only used for uniqueness. For hanzi fonts, recommended values are "fantizi" (traditional) or "jiantizi" (simplified). + DEFAULT_CHAR unsignedInteger This specifies a character code to be used when an attempt is made to display an undefined or non-existent glyph in the font. An HBF file must specify this property. + COPYRIGHT quotedString A human-understandable quoted string that gives the copyright information of the legal owner of the bitmap font file(s). Any copyright information relating to the HBF file should be included in a COMMENT line. + NOTICE quotedString A human-understandable quoted string that gives the copyright information of the legal owner of the font design or, if not applicable, the trademark information for the typeface family. An example full HBF file using more XLFD properties is included as an appendix. 8. ENDPROPERTIES This line indicates the end of the STARTPROPERTIES section. 9. CHARS n n: an unsigned integer specifying the total number of the glyphs in this font. 10. HBF_START_BYTE_2_RANGES r r: an unsigned integer showing how many valid sub-ranges are represented by the byte 2 of the character codes. This section is present if the character code comprises 2 or more bytes. 11. HBF_BYTE_2_RANGE rangeStart-rangeEnd rangeStart, rangeEnd: unsigned integers showing the start and the end value of a valid sub-range represented by the byte 2 of the character codes. It is required that: 0 <= rangeStart <= rangeEnd <= 0xFF. The sub-ranges must be given in increasing order, and must not overlap. E.g., there are two valid sub-ranges of byte 2 values for the Big5 code: HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE 12. HBF_END_BYTE_2_RANGES This line indicates the end of the HBF_START_BYTE_2_RANGES section. The meaning and usage of "HBF_START_BYTE_3_RANGES", "HBF_BYTE_3_RANGE" and "HBF_END_BYTE_3_RANGES" are similar to those for "byte 2". 13. HBF_START_CODE_RANGES r r: an unsigned integer showing how many code-ranges of character code are valid in the whole coding space of the font. 14. HBF_CODE_RANGE firstCode-lastCode bitmapFileName offset firstCode, lastCode: unsigned integers showing the first and the last character code of a valid code range of the coding space of the HBF. For a 2-byte character code, it is required that: 0 <= firstCode <= lastCode <= 0xFFFF. The code ranges must be given in increasing order, and must not overlap. bitmapFileName: an unquoted string of the name of the bitmap file containing the bitmaps for the characters in the code range. The form of the file name will depend on the native operating system, as will its interpretation. However, in most implementations the bitmap file name will be interpreted as if the current directory were the one containing the HBF file. offset: an unsigned integer (at least 32-bits) representing the file offset of the bitmap of the character code firstCode in the bitmap file. See Bitmap File Format for more details on how byte-2 ranges and code ranges describe the structure of the bitmap files. 15. HBF_END_CODE_RANGES This line indicates the end of the HBF_START_CODE_RANGES section. 16. HBF_END_FONT This line marks the end of the HBF file. Note that the X11 BDF file keyword "ENDFONT" is not used. Code Schemes Code schemes are named by one or more tokens. Case is to be ignored in matching these names. Accepted values for HBF_CODE_SCHEME in this specification are: GB 2312-1980 not simply "GB", nor "GB 2312" there are many GuoBiao's for hanzi. Big5 any so-called "Big5" bitmap file(s) can be used, but such bitmap file(s) must conform to the Big5 character code standard without vendor-added character code. The Big5 character code scheme has the following valid code ranges for hanzi: 0xA440-0xC67E for frequently-used hanzi (5401 chars) 0xC940-0xF9D5 for less-frequently-used hanzi (7652 chars) Big5 ETen 3.10 not simply "Big5"; use specifically the bitmap files in the ETen system 3.10 which contains vendor-specific character code. Similar specification of other vendors and software versions are acceptable, to provide a more accurate description. Unicode 1.1 version "1.1", equivalent to ISO/IEC 10646-1 UCS-2, level 3. Perhaps there will be vendor-specific versions at a later date. JIS X0208-1990 Japanese Industrial Standard KS C5601-1987 Korean Standard Code (formingly KIPS) Any additional coding schemes should be discussed on the mailing list "soft-authors@ifcss.org". Bounding Boxes A bounding box is shown below. |<--- width --->| = w - ----------------- - ^ | | | ^ | | | | | ascent | | | | | | | | | | height = h | | | | | baseline ---> - |---O-----------| | point "O" = Origin | | | | | descent = yd | | | | | v | | | v - ----------------- - |<--| xd The values are in pixels of the bitmap. In the fixed pitch fonts that HBF deals with, these parameters will be the same for each character of the font. The HBF_BITMAP_BOUNDING_BOX bounds the bitmap of a glyph; thus its width and height are equal to the width and height of the bitmap. FONTBOUNDINGBOX is a BDF 2.1 property, defining an area within which all glyphs of the font are usually displayed (even if the font is of variable width). In HBF, the FONTBOUNDINGBOX allows for the specification of inter-glyph and inter-line spacing. In many cases, where such control over spacing is not required, the sizes of HBF_BITMAP_BOUNDING_BOX and FONTBOUNDINGBOX are the same. In all cases, the bitmap bounding box must fit withis the font bounding box. In an application, a line of text may contain glyphs from more than one font. The glyphs must be aligned along the horizontal "baseline" of the line of text. The baseline contains the "origins" of the glyph bounding boxes. The origin of a bounding box may not be at the lower left corner of the bounding box because some letters in a Latin font, like 'g', 'j', 'Q', etc., have "descenders" extending below the baseline. The xd and yd values of a bounding box specify the offset of the lower left corner of the bounding box from the origin. In such cases, the yd value of both bounding boxes may be non-zero due to the need to align neatly with a Latin font along a line of text. E.g., use FONTBOUNDINGBOX 24 24 0 -4 instead of FONTBOUNDINGBOX 24 24 0 0 to align with a Latin font with "FONTBOUNDINGBOX 12 24 0 -4" which contains letters with descent "-4", such as 'g', 'j', 'Q', etc. The following shows an example of unequal bitmap and font bounding boxes. Suppose the HBF file contains the lines FONTBOUNDINGBOX 16 18 0 -2 and (indicating a 16x15 bitmap) HBF_BITMAP_BOUNDING_BOX 16 15 0 -1 In the following diagram, the boundary of the font bounding box is dashed, while the boundary of the bitmap bounding box is dotted: |<--- width --->| = 16 ----------------- - a blank row--> | | ^ a blank row--> | | | |...............| - | |///////////////| ^ | |///////////////| | | |// 16x15 /////| | | |// bitmap /////| |15 |18 = FONTBOUNDINGBOX height. |///////////////| | | |///////////////| | | baseline ----> O---------------- | | point "O" = Origin (0,0) |///////////////| v | -1|...............| - | -1 = yd of HBF_BITMAP_BOUNDING_BOX. a blank row--> | | v -2----------------- - -2 = yd of FONTBOUNDINGBOX. Note that the origins of the two bounding boxes are identified. The following are some more examples to illustrate the relationships between FONTBOUNDINGBOX and HBF_BITMAP_BOUNDING_BOX. Suppose we have five HBF files: HBF1, HBF2, HBF3, HBF4, HBF5. 16x16 bitmap HBFs HBF1: (HBF_BITMAP_BOUNDING_BOX and FONTBOUNDINGBOX are the same.) HBF_BITMAP_BOUNDING_BOX 16 16 0 -2 FONTBOUNDINGBOX 16 16 0 -2 HBF2: (to allow for inter-line spacing of 2 pixels with the glyph bitmap aligned at the bottom of the FONTBOUNDINGBOX) HBF_BITMAP_BOUNDING_BOX 16 16 0 -2 FONTBOUNDINGBOX 16 18 0 -2 16x15 bitmap HBFs HBF3: (to be aligned at the top of HBF1 glyph bitmap when shown with HBF1) HBF_BITMAP_BOUNDING_BOX 16 15 0 -1 FONTBOUNDINGBOX 16 16 0 -2 HBF4: (to be aligned at the bottom of HBF1 glyph bitmap when shown with HBF1) HBF_BITMAP_BOUNDING_BOX 16 15 0 -2 FONTBOUNDINGBOX 16 16 0 -2 HBF5: (to be aligned at the top of HBF2 glyph bitmap when shown with HBF2 and using the same FONTBOUNDINGBOX as HBF2) HBF_BITMAP_BOUNDING_BOX 16 15 0 -1 FONTBOUNDINGBOX 16 18 0 -2 Bitmap File Format A "bitmap file" is a binary file of character bitmaps indexed by the corresponding HBF file. The format described below is fairly common; in particular many bitmap fonts supplied by vendors may be used without modification. Structure of a Bitmap A bitmap of size "Width x Height" bits is stored by rows from top to bottom, with each row taking up a whole number of bytes. Thus each row occupies (Width+7)/8 bytes, where integer division with truncation of decimal places is used in the calculation. Each row is stored from left to right, with the leftmost pixel in the most significant bit of the first byte. Hence each bitmap occupies Height*((Width+7)/8) bytes. For example, * a 16x16 bitmap occupies 16*((16+7)/8) = 32 bytes * a 15x16 bitmap occupies 16*((15+7)/8) = 32 bytes * a 16x15 bitmap occupies 15*((16+7)/8) = 30 bytes * a 64x64 bitmap occupies 64*((64+7)/8) = 512 bytes A bit value of 1 represents part of the character, while a value of 0 indicates the background. Arrangement of Bitmaps in the File Each HBF_CODE_RANGE entry in the HBF file gives an offset into a bitmap file at which the bitmaps for a range of characters may be found. The bitmaps for characters from firstCode to lastCode are stored sequentially in the file, but bitmaps for codes outside the defined byte-2 range are omitted. For example, suppose we have a 24x24 Big5 font, so that each bitmap occupies 72 bytes. In Big5, the ranges for the second byte are: HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE An entry of the form HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0 means that the offsets of bitmaps in the file are 0 bitmap for character A440 72 bitmap for character A441 ... ... 4464 bitmap for character A47E 4536 bitmap for character A4A1 ... ... 11232 bitmap for character A4FE 11304 bitmap for character A5A1 ... ... 395568 bitmap for character C67E Simple Example of an HBF File The following is an example simple HBF file which uses the bitmap files supplied in the ETen system Version 3.10. HBF_START_FONT 1.1 HBF_CODE_SCHEME Big5 ETen 3.10 FONT eb5-24k SIZE 24 72 72 HBF_BITMAP_BOUNDING_BOX 24 24 0 -2 FONTBOUNDINGBOX 24 24 0 -2 COMMENT Begin Logical Font Description -- 5 special properties for this FONT STARTPROPERTIES 5 FAMILY_NAME "Kai" ADD_STYLE_NAME "fantizi" DEFAULT_CHAR 0xA140 COMMENT Public domain simple HBF file (1993) COMMENT The following lines relate to the bitmaps and typeface COPYRIGHT "(c) 1988, 1992 ETen Information System Corp" NOTICE "The bitmap files are that of ETen system 3.10 or the equivalent." ENDPROPERTIES CHARS 13943 HBF_START_BYTE_2_RANGES 2 HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES COMMENT HBF_START_CODE_RANGES 4 HBF_CODE_RANGE 0xA140-0xA3E0 spcfont.24 0 HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0 HBF_CODE_RANGE 0xC6A1-0xC8FE spcfsupp.24 0 HBF_CODE_RANGE 0xC940-0xF9FE stdfont.24k 388872 HBF_END_CODE_RANGES COMMENT COMMENT Non-hanzi symbol (441 chars) bitmaps in file "SPCFONT.24". COMMENT Vendor-specific symbols (408 chars) bitmaps in file "SPCFSUPP.24K". COMMENT Frequently-used hanzi (5401 chars) bitmaps followed by COMMENT less-frequently-used hanzi (7693 chars) bitmaps in file "STDFONT.24K". COMMENT COMMENT For the fourth HBF_CODE_RANGE of less-frequently-used hanzi, COMMENT the range is smaller in standard Big5: 0xC940-0xF9D5 (7652 chars); COMMENT and the offset 388872 bytes from the start of the file "STDFONT.24K" COMMENT is based on the information supplied by COMMENT Stephen G. Simpson COMMENT -- these may vary depending on the version of the ETen system. HBF_END_FONT Sample Full HBF Header File The following is an example full HBF file which uses the bitmap files supplied in the ETen System Version 3.10. HBF_START_FONT 1.1 HBF_CODE_SCHEME Big5 ETen 3.10 FONT eb5-24k COMMENT COMMENT An equivalent full XLFD 1.5 conforming font name is COMMENT -ETen-Kai-medium-r-normal-fantizi-24-240-75-75-c-240-Big5.ETen.3.10-1 COMMENT which is formed from the first 15 properties listed in COMMENT the STARTPROPERTIES section below. COMMENT Any of these properties is optional, as in the simple HBF file. COMMENT Modified by cyl@ifcss.org 1994.7.16 COMMENT SIZE 24 72 72 HBF_BITMAP_BOUNDING_BOX 24 24 0 -2 FONTBOUNDINGBOX 24 24 0 -2 COMMENT COMMENT Begin Logical Font Description -- 20 special properties for this FONT COMMENT STARTPROPERTIES 20 FONTNAME_REGISTRY "" FOUNDRY "ETen" FAMILY_NAME "Kai" WEIGHT_NAME "medium" SLANT "r" SETWIDTH_NAME "normal" ADD_STYLE_NAME "fantizi" PIXEL_SIZE 24 POINT_SIZE 240 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING "c" AVERAGE_WIDTH 240 COMMENT '-' can't be used in full XLFD name, thus use '.' in CHARSET_REGISTRY CHARSET_REGISTRY "Big5.ETen.3.10" CHARSET_ENCODING "1" FONT_ASCENT 22 FONT_DESCENT 2 COMMENT COMMENT All the above properties are discussed in XLFD Conventions 1.5. COMMENT COMMENT The rest is the same as the simple HBF file. COMMENT DEFAULT_CHAR 0xA140 COMMENT 0xA140 is the Space character. COPYRIGHT "(c) 1988, 1992 ETen Information System Corp" NOTICE "The bitmap files are that of ETen System 3.10 or the equivalent." ENDPROPERTIES COMMENT Users should observe the copyright of the individual bitmap font files. COMMENT This HBF header file is in the public domain (1994) CHARS 13943 HBF_START_BYTE_2_RANGES 2 HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES HBF_START_CODE_RANGES 4 HBF_CODE_RANGE 0xA140-0xA3E0 spcfont.24 0 HBF_CODE_RANGE 0xA440-0xC67E stdfont.24k 0 HBF_CODE_RANGE 0xC6A1-0xC8FE spcfsupp.24 0 HBF_CODE_RANGE 0xC940-0xF9FE stdfont.24k 388872 HBF_END_CODE_RANGES COMMENT 0xA140-0xA3E0 is 408 Big5 specific punctuation, numerals, COMMENT Roman, Greek, Bopomofo Alphabet and 33 COMMENT Control characters COMMENT 0xA440-0xC67E is 5401 frequently used Big5 Chinese COMMENT characters. COMMENT 0xC6A1-0xC8FE is 408 ETen specific numerals, Japanese and COMMENT Russian alphabets, etc. COMMENT 0xC940-0xF9FE is 7652 less frequently used Big5 Chinese COMMENT characters and 41 other ETen specific COMMENT characters. HBF_END_FONT History of this Document Version 1.0 [ftp: ifcss.org software/fonts/hbf-discussion/HBF_std_v1.0] of this document was written by Man-Chi Pong, as a result of discussion via e-mail among a group of Chinese software developers who would like to see a standard way to access hanzi (Chinese character) bitmap files. The following is a list, in alphabetic order of the surnames, of the contributors to the discussion. CAI@neurophys.wisc.edu (CAI, Yidao) jiang@ifcss.org (JIANG, Yuan) lee@umunhum.stanford.edu (LEE, Fung Fung) A7621GAC@AWIUNI11.EDVZ.UniVie.AC.AT (LEMBERG, Werner) 87P0786@csdvax.csd.unsw.edu.au (NI, Hongbo) mcpong@cs.ust.hk (PONG, Man-Chi) simpson@math.psu.edu (SIMPSON, Stephen G.) tee@ecf.toronto.edu (TEE, Luns) yawei@bronze.ucs.indiana.edu (WEI, Ya-Gui) eric@coeus.ucsd.edu (YANG, Bo) Ricky.Yeung@eng.sun.cOM (YEUNG, Ricky) FARZ%NMUMUS.bitnet@vmd.cso.uiuc.edu (ZHANG, Roxin) ygz@cs.purdue.edu (ZHANG, Yongguang) All previous mail exchanges, related programs, the names in the mailing list (soft.list), etc., are ftp'able [ftp: ifcss.org software/fonts/hbf-discussion/]. The following revisions culminated in version 1.0: Draft 0.1 (1993/02/17) Draft 0.2 (1993/02/28) + All property keywords related to HBF starts with "HBF_". + "_" is used to separate the English words in the HBF keywords to make them more readable. + "ENCODING" is renamed as "HBF_CODE_SCHEME" because "ENCODING" in X BDF means the hanzi code value of a glyph. + "SEGMENT" is renamed as "HBF_CODE_RANGE"; more suggestive. Draft 0.3 [ftp: ifcss.org software/fonts/hbf-discussion/HBF_std_v1.0_d0.3] (1993/03/15) + uniform naming of keywords: HBF_xxx_yyy. + cut the details of X11R5 XLDF and BDF properties. + simplify API. Draft 0.4 [ftp: ifcss.org software/fonts/hbf-discussion/HBF_std_v1.0_d0.4] (1993/04/30) + found in BDF [2] that " can be used in a string (use ""). + FONTBOUNDINGBOX & HBF_BITMAP_BOUNDING_BOX can have -ve xd yd; BNF in Appendix 1 updated. + changes in API HBF_OpenFont() HBF_GetBitmap() and API routines return 0 if OK, non-zero if not OK. Draft 0.5 [ftp: ifcss.org software/fonts/hbf-discussion/HBF_std_v1.0_d0.5] (1993/05/28) + mention that HBF file name convention is not part of this standard. + some minor presentation changes. Adopted as version 1.0. The revisions leading to version 1.1 were coordinated by Nelson Chin (Chen Yilong). They were: Draft 1.01 (1994/07/19) + all references to X11R5 changed to X11R6. [cyl@ifcss.org] + all references to HBF v1.0 changed to v1.1 [cyl@ifcss.org] + added JISX0208-1990 and KSC5601-1987 as valid HBF_CODE_SCHEMEs [rap@doc.ic.ac.uk] + The bit about vendor versions of Unicode is wrong. v1.1 comes first; vendor extensions of it may come later. [rap@doc.ic.ac.uk] Draft 1.02 (1994/07/20) + "COPYRIGHT" of HBF file is now identified with "COMMENT" line. [rap@doc.ic.ac.uk] + "COPYRIGHT" & "NOTICE" definitions changed to conform to X11R6 BDF/XFLD properties. [rap@doc.ic.ac.uk] + appendix 2 proposed API implementation removed, to keep HBF Standard describing only file format. + all references to ETen 2.00.03 changed to 3.10 [cyl@ifcss.org] + section 4 descriptions of full HBF merged into section 3 STARTPROPERTIES explanation, and section 4 example of full HBF is now appendix 2. [rap@doc.ic.ac.uk] Draft 1.03 (1994/07/22) + reference to Ross Paterson's sample API implementation and availability added to section 1. [nsysu11@cc.nsysu.edu.tw] + Reference part at end of section 1 moved out of HBF Standard into Appendix 3 as Endnotes. [cai@neurophys.wisc.edu] + section 3 (2) HBF_CODE_SCHEME explanation updated.[rap] + discarded the "v" in front of version numbers when used in HBF_CODE_SCHEME, as it's not used in the similar XLFD property CHARSET_REGISTRY. [cyl@ifcss.org] Draft 1.04 (1994/07/23) + many references to "hanzi" changed to "character" in the text of this Standard to reflect support of any uniform bitmaps, and not just hanzi bitmaps. [rap@doc.ic.ac.uk] Draft 1.05 (1994/07/25) + all references to X11R6 BDF and X11R6 XLFD changed to BDF 2.1 and XLFD 1.5, respectively, since BDF hasn't changed for two X11 revisions. [rap] + implementation note appended to bitmapFileName. [rap] + correction to STARTPROPERTIES p, which stated that in BDF p is optional. Should be the whole properties section is optional.[rap] + specs for single and triple byte fonts added. [cai] Draft 1.06 (1994/07/27) + converted document to HTML. Some restructuring and stylistic changes.[rap] + added description of SIZE entry (required for BDF compatability).[rap] + moved case-insensitivity to FONT and HBF_CODE_SCHEME (since others may not be case-insensitive; bitmap filenames certainly aren't).[rap] From rap@doc.ic.ac.uk Wed Aug 31 13:29:48 1994 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA07064; Wed, 31 Aug 94 13:29:48 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qfuNG-00070kC; Wed, 31 Aug 94 19:27 BST Message-Id: Date: Wed, 31 Aug 94 19:27 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF 1.1 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To repeat an earlier suggestion: How about making CHARS optional? It's only there for BDF compatability, is a nuisance to get right, and could be computed by hbftobdf.