From mcpong@uxmail.ust.hk Sat Jan 30 01:51:07 1993 Return-Path: Date: Sat, 30 Jan 93 15:48:31 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: xiaofei@ifcss.org Subject: Re: bitmapped_fonts Cc: ccvictor@uxmail.ust.hk, pklai@uxmail.ust.hk Status: RO > Hi, I would like to invite you for an informal and small scale discussion > on chinese bitmapped fonts. Please add ccvictor@uxmail.ust.hk pklai@uxmail.ust.hk Thanks. ------- Some of those in your mailing list have discussed the problem some time ago. We more or less come to something like the following as the "canonical format": some header information like those fonts in X window system region-range1 (Qu) the valid-hanzi-codes in the Qu (i.e. Wei) region-range2 (Qu) the valid-hanzi-codes in the Qu (i.e. Wei) ... then raw-bit-maps arranged row-wise sequentially, (no gap for non-existing hanzi). (These bitmaps can be in a separate file, and using something like "#include file" to access it.) This format can be defined formally. We stop short of defining it completely, due to limited free time. I suppose lee@umunhum.stanford.edu will reply something to you because he first proposed the idea of "region-range-i valid-hanzi-codes". Let's wait for his summary, hopefully. (Now I can't find the discussion I saved previously. Sorry.) Cheers! mcpong From ygz@cs.purdue.edu Sat Jan 30 10:59:41 1993 Return-Path: To: xiaofei@ifcss.org (XiaoFei Wang) Subject: Re: bitmapped_fonts Cc: eric@coeus.ucsd.edu, lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu In-Reply-To: Your message of Sat, 30 Jan 1993 01:21:04 -0600. <9301300721.AA16058@ifcss.org> Date: Sat, 30 Jan 1993 11:58:24 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: RO Hi, In message <9301300721.AA16058@ifcss.org> XiaoFei Wang writes > Hi, I would like to invite you for an informal and small scale discussion > on chinese bitmapped fonts. The people I have contacted is list below. > If you are not interested in the discussion please email me so that I > will remove you from the distribution list. If you are, I should have a mail > alias ready tomorrow so that you can use to communicate with other > programmers. I hope some agreement can be reached. Yes, we support the effort for standardizing the bitmap fonts. We can clearly see the need for this from your message log. Actually some of us had a month-long discussion about this issue last October. We even came up some consensus on a common format for Chinese bitmap fonts. I suggest we post the thread of our discussion to xiaofei's list. Does anyone have a complete archive of all the email messages of our discussion? My archive seems incomplete. And how is the status of our HBF now? -ygz === P.S. The first & last message of the thread in my log: (How this thread was started) Date: Thu, 8 Oct 92 17:15:36 -0700 From: lee@rinconada.Stanford.EDU (Fung Fung Lee) Message-Id: <9210090015.AA02357@rinconada.Stanford.EDU> To: ygz Subject: Public Domain BIG5 Fonts Discovered Cc: yawei@bronze.ucs.indiana.edu, lai@apple.com, eric@sdphu1.ucsd.edu, ryeung@hk.eng.sun.com Dear Yongguang: [ ... there are big5 fonts in some ftp site in .tw ... ] These huge files remind me of Ricky Yeung's suggestion on a.c.t. some time ago that there should be a common font file format for our Chinese software. The bdf format is fine, except that it is usually more than 2 to 3 times the raw bitmap size, and needs to be converted to something like pcf format for actual use. It seems to me that cclib's format does not include information about bitmap size and copyright, etc. For non X-window program, it appears to me that a good common Chinese bitmap font file format can be a combination of bdf's attribute statements / comments followed by consecutive blocks of bitmap in the valid code ranges. Better yet, a set of library routines defined to interact with the format, so that future programmers do not have to worry about the details and can be sure that there is a pool of compatible fonts. I think this is a worthwhile effort. What do you think? I would be happy to write a draft if not for the fact that I will be very busy until the end of this year. sigh :-! Fung ---------------------------------------------------------------------- Appendix. [a list of big5 fonts deleted] ============= Date: Wed, 11 Nov 92 17:33:14 -0800 From: eric@coeus.ucsd.edu (Bo Yang) Message-Id: <9211120133.AA12079@coeus.ucsd.edu> To: lee@rinconada.stanford.edu Subject: Re: HBF (Hanzi Bitmap Format) Cc: eric@coeus.ucsd.edu, lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz Just an idea: should we include a property line saying if data compression of the rawbits is used? It seems to me that for large bitmaps Chinese fonts, even a simple(fast) compression algorithm can save a lot of space. It will be up to the user to decide which algorithm to use and how to index the compressed rawbits/plans. There might be a standard for it later. Just leave a possibility open for future use... -- Bo Yang From yawei@bronze.ucs.indiana.edu Sat Jan 30 10:51:36 1993 Return-Path: Date: Sat, 30 Jan 1993 11:50:42 -0500 From: ~{QG9p~} To: xiaofei@ifcss.org, yawei@bronze.ucs.indiana.edu Subject: Re: bitmapped_fonts Status: RO Hi Xiaofei, You may leave my address in there for now. Thanks. It's not clear to me what these guys are talking about. It seems the "compressed" fonts they are talking about are not "compressed" at all, but merely with some (unused) coding spaces taken out. This is true for almost all cclib fonts. ZWDOS 2.2 has paid attention to that by providing the /fg command line switch, which the user can adapt to different variations of cclib fonts. Some of the guys in your list (FFL, Bo Yang et al) has been engaged in one round of such discussions before, in which I was a listener. I am not sure of all participants of that discussion are currently in your list. I can perhaps dig out one of those messages for you to at least invite some more people in. I didn't paid much attention to the previous discussion because I didn't see it as an important issue. A software developer can easily twist his/her programs to work with almost any font files as long as the format is known. But I do agree that it is an important issue that, handled properly, can reduce confusion and disk space on the part of the user. Perhaps you can have a directory (/software/fonts/d) to store some of the results of the discussions. Ya-Gui From yawei@bronze.ucs.indiana.edu Sat Jan 30 10:58:30 1993 Return-Path: Date: Sat, 30 Jan 1993 11:57:40 -0500 From: ~{QG9p~} To: xiaofei@ifcss.org, yawei@bronze.ucs.indiana.edu Subject: Re: bitmapped_fonts Status: RO I just checked. It seems you have covered all the participants of the previous discussion. The previous discussion resulted in some kind of font spec, which I don't know how useful it is, but you can get it from FFL or Bo Yang of YGZ I think. Ya-Gui From CAI@neurophys.wisc.edu Sat Jan 30 17:10:15 1993 Return-Path: Date: Sat, 30 Jan 93 16:59 CST From: CAI@neurophys.wisc.edu Subject: Font Name To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO ************** From: IN%"xiaofei@ifcss.ORG" 30-JAN-1993 15:37:35.91 To: CAI@neurophys.wisc.edu ...Guess I answered your questions. Do you want begin the discussion by answering yawei's question? I have generated all the fonts: cclibj.24 cclibf.24 cclibh.24 : hei style cclibb.24 : fan song style cclibk.24 : kai style see if they can be recognized as 'standard' set of fonts. A stupid question, I think a font, theoretically should be described by 2 parameters, jian or fan, and then each category is further divided into song, hei, kai, etc. Now we put 'j' and 'k' paralell, they are not paralell at all. ********************** I agree. I think the present catagory is due to the fact that there is only one 24x24 Fanti font in public domain and the 24x24 Jianti font (Song ?) happened to be the most popular one, so practically there is not much confusion. Since we are disscussing a standard, if would be better to look ahead. So I think it is a good idea to identify the fonts by Jianti or Fanti, style (e.g. Song, hei, kai, etc), size (16x16, 24x24, etc). For example cclibj.h24 Simplified, Heiti, 24x24 cclibf.k16 Non-simplified, Kaishu, 16x16 Yidao From yawei@bronze.ucs.indiana.edu Sat Jan 30 18:19:35 1993 Return-Path: Date: Sat, 30 Jan 1993 19:12:45 -0500 From: ~{QG9p~} To: CAI@neurophys.wisc.edu, soft-authors@ifcss.org Subject: Re: Font Name Status: RO Well you have to consider that there will be multiple different fantizi Kaishu 24x24 fonts as well.... From 87P0786@csdvax.csd.unsw.EDU.AU Sat Jan 30 18:36:17 1993 Return-Path: <87P0786@csdvax.csd.unsw.EDU.AU> Date: 31 Jan 1993 11:30:07 +1000 From: "Hongbo Ni ~{D_:h2(~}" <87P0786@csdvax.csd.unsw.EDU.AU> Subject: Proposed standard for Chinese font To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Status: RO Proposed Standard of Chinese Font - by Hongbo Ni (Author of NJSTAR) ---------------------------------------------------------------------------- 1. Naming Protocol CCLIBxy.nn x - indicates it is a FanTi (f) or JianTi (j) font, or ASCII (A). User Defined (u). y - indicates font style: s-SongTi f-FangSong k-KaiTi h-Heiti and other (for 16x16 font, y is not necessary) nn - font size: .16 .24 .32 .48 etc.. Examples: CCLIBJ.16 - JianTi 16x16 (Qu:1 to Qu:87, size 87x94x32) CCLIBF.16 - FanTi 16x16 (Qu:1 to Qu:87, size 87x94x32) CCLIBU.16 - User Defined 16x16 (Qu:88 to Qu:94, size 7x94x32) CCLIBAS.24 - Chinese Ascii symbols (Qu:1 to Qu:15, size 15x94x72) CCLIBUS.24 - User Defined 24x24 (Qu:88 to Qu:94, size 7x94x72) CCLIBJS.24 - JianTi SongTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBJF.24 - JianTi FangSongTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBJK.24 - JianTi kaiTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBJH.24 - JianTi HeiTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBFS.24 - FanTi SongTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBFF.24 - FanTi FangSongTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBFK.24 - FanTi kaiTi 24x24 (Qu:16 to Qu:87, size 72x94x72) CCLIBFH.24 - FanTi HeiTi 24x24 (Qu:16 to Qu:87, size 72x94x72) Same naming convention should also apply to any higher resolution fonts. 2. Font Format and Byte Order All fonts should be in Bitmap format, that is one bit per dot. For 16x16 font, there is 2 bytes per row, 32 bytes per character (16 rows), no more no less. For 24x24 font, there is 72 (24x24/8) bytes per character. Byte Order is show in following chart (for 16x16 font). That is the correct order for display, HP laserjet, deskjet, Canon Laser and Postscript. Rotation of the font for 9 pin and 24 pin printer should be done by the software internally without changing the font. 1111111122222222 3333333344444444 5555555566666666 7777777788888888 99999999aaaaaaaa ........ 3. Characters Encoded in each font file For 24x24 font, all the symbols are in one file CCLIBAS.24. so no disk space will be wasted even all Qu 1 to Qu 15 are defined. Each software may have their own CCLIBAS.24 with Qu 10 to Qu 15 filled with their own characters. User may define more 24x24 characters to cover chars not in GB-2132/80, and store it in file CCLIBUS.24 All other 24x24 font only store Chinese characters (Qu 16 to Qu 78) in different styles. So all program should display/print the same Chinese Character even Qu 10 to Qu 15 are defined differently. Since 16x16 fonts are normally for display, Chinese Symbols are kept with Chinese character in both 16x16 fonts, so only one file needs to be opened at the same time for easy access. CCLIBJ.16 and CCLIBF.16 should have all the Sections (Qu) defined, including Qu 10 to Qu 15. This makes sure its upward compatibility. Editor/Viewers, who load 16x16 font into RAM, can skip reading the data of Qu 10 to Qu 15. User may define more 16x16 characters to cover chars not in GB-2132/80, and store it in file CCLIBUS.16 Reading of user defined font is up to the program author. 4. Font Storage recommendation. User can store all the font files in a subdirectory independent of software program. say c:\CCLIB (or other name on other platform). An environment variable CCLIB can be defined by the user set CCLIB=C:\CCLIB (on DOS's autoexec.bat file) All programs should read this environment variable in order to locate CCLIB files. AND/OR a program (PROG.EXE) should read a text file PROG.INI, in which CCLIB can also be defined with a line CCLIB=C:\CCLIB If PROG.EXE did not find fonts in above two setting, it should try to locate it in same directory as PROG.EXE and/or current directory. 5. Problems The biggest problem is all of us (the Authors) have to modify the code ;-( Not every one can do it now, so there is a transition time. It is recommended that all new uploads to IFCSS.ORG should confirm to the final standard. It will benefit whole CSS community in the long run. :-). From lee@fritter.Stanford.EDU Sat Jan 30 22:06:04 1993 Return-Path: Date: Sat, 30 Jan 93 19:57:31 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: HBF (Hanzi Bitmap Format) Status: RO (This is a long article, containing 13 previous email exchanges on HBF.) Dear soft-authors: I am glad to see that the "font" problem has finally received enough attention to justify the creation of this mailing list. Around October 1992, a few of us actually had a round of discussion on this issue, and reached basic agreements on the essential characteristics of a new font file format, HBF (Hanzi Bitmap Format) (see ARTICLE 8). We were about to write a draft proposal (see ARTICLE 9). Unfortunately, most of us have been too busy to complete the draft as planned. Therefore, in short of a standalone proposal for HBF, I have extracted the following email exchanges, which documents the progress of ideas leading to the current version of HBF (Scheme C of ARTICLE 8), and our initial response. In retrospect, these exchanges reflect some of our own mistakes and misconceptions; hopefully the readers will benefit from knowing some of the pitfalls. The basic characteristics about HBF are 1. A HBF font file should contain all the relevant font attributes, such as font name, size, style, copyright in a header region at the beginning of a file. This is similar to X window system's BDF. In other words, this information is explicitly encoded in the file contents but not in the file name (cf. CCDOS' convnetion). 2. It takes advantage of the fact that hanzi fonts (Chinese, Japanese kanji) are fixed-pitch fonts. Hence, there is no need for attribute description for individual characters as done in X's BDF. 3. It should support random access of the bitmap of any individual character efficiently and directly, without being first compiled into something like X's PCF or SNF or other vendor specific internal format. 4. Recognizing the fact that most Chinese font files differ only mainly in valid code ranges supported and bitmap ordering and location byte offset regardless of the code is GB, BIG5 or even UNICODE, we design HBF with sufficently flexible index structures such that it can describe virtually all known popular GB and BIG5 font file structures. The raw bitmap in an existing font file can be "pointed" at appropriately by the index so that there is no need to touch the original file at all. This can be a big advantage. For example, users with existing Chinese OS such as CCDOS or ETen only need to create a small .hbf file for each of his/her font file which contains the actual bitmap. Many proprietary font files (not in the public domain) can be used by simply filling out a small number of byte offset constants in the corresponding .hbf. Currently, all the bitmap belonging to a font must be in one file. This is a pending issue whether several files should be allowed. See HongBo Ni's posted proposal a few hours ago. For the details of the indexing scheme, see Scheme C of ARTICLE 8. As for the raw bitmap itself, HBF for now assumes the common case: the most significant bit of the first byte is the upper-left bit of the characer image; the least significant bit of the last byte is the lower-right bit of the image. The scanning order is top to bottom, left to right; black is 1, white is 0 (or the other way?); the number of bytes per image is exactly equal to H x W / 8 bytes, where H is the height, W is the width of the image. (I think we should consider non-square images.) Well, I think we can first decide on the scope (GB/BIG5/Unicode/...), the goal and the complexity/flexibility we desire. >From the simple demand of saving disk space to powerful index structures, HBF traveled farther than I had expected. As you can see from the articles, the above basic characteristics of HBF was the result of the open interaction among the participants. As far as I am concerned, HBF is not finalized and is open to suggestions. Best regards, Fung F. Lee (Search for "%ARTICLE" for the beginning of each article.) ============================================================================ %ARTICLE 1 ============================================================================ >From eric@coeus.ucsd.edu Sun Oct 18 16:39:04 1992 Date: Wed, 14 Oct 92 15:56:05 -0700 From: eric@coeus.ucsd.edu (Bo Yang) To: lee@rinconada.stanford.edu Subject: Some Considerations about the Common Bitmap Chinese Font format Cc: eric@coeus.ucsd.edu, lai@apple.com, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu Thanks for forwarding the discussions to me. It seems that we have agreed on the "header + raw bitmaps" format. What is worrisome is the compexity of different Chinese coding themes, also the un-defined areas inside the leagal coding ranges. Some existing fonts exlude these regions from their continues bitmap blocks, which is not a bad idea considering the amont of spaces needed to store Chinese fonts, but further increased the confusion. So about the new format: 1. The format should be able to work with the existing char-sets, and future unknown char-sets. i.e., the code-range information should be included. 2. It should also permit the existance of partial-char-set fonts, like a GB or BIG5 font without the uncommon characters. This is a must for an UNICODE- coded Chinese font. 3. There's no obvious reason why the size of the char-planes (or the range of the 2nd byte) should be fixed for all planes. Plus, some space could be saved if variable sized planes are used. 4. Providing coding information for every character( like in BDF) would waste a lot of spaces. Also at least for the exsisting char-sets most of the byte planes are fix-sized. My suggestion is to include an "index" area between the header and the raw bits. The characters are then divided into some continues blocks according to their high and low byte ranges. The starting position and length of the bitmaps for these characters is recorded. Here is an example: ( header) BCF92 ( whatever, a magic number) BeginFont BeginHeader 34 Name: BIG5Standard16 CharSet: BIG5 Size: 16 16 ... (other infomation) EndHeader BeginIndex 2 <-- size of the index area, in blocks or bytes A1 F9 40 7E at 1 179428 <--ranges of 1st and 2nd bytes, at, postition A1 F9 A1 FE at 179429 447136 of bitmaps EndIndex BeginBitmap 447136 (447136 raw bytes) EndBitmap EndFont This is for cclib24: BeginIndex 1 A1 F7 A1 FE at 1 588816 EndIndex This is for cclib16: BeginIndex 2 A1 A7 A1 FE at 1 21056 B0 F7 A1 FE at 21057 237632 EndIndex For Chinese16 styled compact BIG5 16( 2nd underfined plane excluded): BeginIndex 5 A1 C5 40 7E at 1 ... ( Non-Chinese, Frequently used Chinese) A1 C5 A1 FE at ... C6 C6 40 7E at ... C9 F9 40 7E at ... ( Not-Frequently used Chinese) C9 F9 A1 FE at ... EndIndex The subroutines for locating bitmap from a two-byte character code can be easily standarlized. Just an idea. Regards. -- Yang, Bo ~{Qn 2*~} ============================================================================ %ARTICLE 2 ============================================================================ >From ygz@cs.purdue.edu Sun Oct 18 16:39:13 1992 To: eric@coeus.ucsd.edu (Bo Yang) Cc: lee@rinconada.stanford.edu, lai@apple.com, yawei@bronze.ucs.indiana.edu Subject: Re: Some Considerations about the Common Bitmap Chinese Font format In-Reply-To: Your message of Wed, 14 Oct 92 15:56:05 -0700. <9210142256.AA02996@coeus.ucsd.edu> Date: Wed, 14 Oct 92 22:51:17 EST From: ygz@cs.purdue.edu (Yongguang Zhang) > ( header) > BCF92 ( whatever, a magic number) > BeginFont > > BeginHeader 34 > Name: BIG5Standard16 > CharSet: BIG5 > Size: 16 16 > ... (other infomation) > EndHeader > > BeginIndex 2 <-- size of the index area, in blocks or bytes > A1 F9 40 7E at 1 179428 <--ranges of 1st and 2nd bytes, at, postition > A1 F9 A1 FE at 179429 447136 of bitmaps > EndIndex > > BeginBitmap 447136 > (447136 raw bytes) > EndBitmap > > EndFont I'll add that an alternative to BeginBitmap 447136 (447136 raw bytes) EndBitmap may be a pointer to the cclib-like raw bitmap file: BitmapFile "cclib24" <-- the pathname of the file where bitmaps are stored In this case, this header can be regarded as a supplement to the "real" bitmap file. We can reuse all the cclib or ETen font files by writing a header for each of them. Just some comment. Cheers, --ygz ============================================================================ %ARTICLE 3 ============================================================================ >From lee@rinconada.stanford.edu Sun Oct 18 16:39:18 1992 Date: Wed, 14 Oct 92 21:23:07 -0700 From: lee@rinconada.stanford.edu (Fung Fung Lee) To: ryeung@hk.eng.sun.com, eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@uxmail.ust.hk, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu, lee@umunhum.stanford.edu In-Reply-To: Bo Yang's message of Wed, 14 Oct 92 15:56:05 -0700 <9210142256.AA02996@coeus.ucsd.edu> Subject: Re: Some Considerations about the Common Bitmap Chinese Font format Before writing my response to Bo Yang's draft proposal about a common hanzi (Han characters as called in Unicode) bitmap font format (.hbf ?), I would like to take this chance to list the names on this mailing list. (The program names listed are hanzi display software I know of, and are not supposed to form an exhaustive list.) If most of us do not agree on and lend support to the common format, then there is not much advantage in practice. author software ---------------------------------------------------------------- eric@sdphu1.ucsd.edu Yang, Bo Chirk lai@apple.com Lai, Ed SubTitle lee@umunhum.stanford.edu Lee, Fung Fung hz2ps, hzview mcpong@uxmail.ust.hk Pong, Man Chi cxterm ryeung@hk.eng.sun.com Yeung, Ricky xhzview william@anucsd.anu.edu.au Sun, William gb2ps yawei@bronze.ucs.indiana.edu Wei, Yagui zwdos ygz@cs.purdue.edu Zhang,Yongguang cxterm Bo Yang wrote: >Thanks for forwarding the discussions to me. It seems that we have agreed >on the "header + raw bitmaps" format. What is worrisome is the compexity of I am not sure if "we" have agreed on the "header + raw bitmaps" format, because some of "us" are either new to this mailing list, or have kept silient so far. But let "us" go ahead as far as discussions are concerned. Please let "us" know if you are not interested and do not want to be on the mailing list. >different Chinese coding themes, also the un-defined areas inside the leagal >coding ranges. Some existing fonts exlude these regions from their continues >bitmap blocks, which is not a bad idea considering the amont of spaces needed to >store Chinese fonts, but further increased the confusion. So about the new >format: >1. The format should be able to work with the existing char-sets, and future > unknown char-sets. i.e., the code-range information should be included. I agree. The code range information should be explicit as in BDF instead of being implicit as in cclib. In addition, HBF should be complete, as M.C. Pong pointed out, in the sense that HBF and BDF should be equivalent as long as all the bitmaps are of the same size and same other attributes. >2. It should also permit the existance of partial-char-set fonts, like a GB or > BIG5 font without the uncommon characters. This is a must for an UNICODE- > coded Chinese font. Yes, I agree too. Since Unicode actually contains non-Chinese hanzi (Han characters), including made-in-Japan, and made-in-Korea hanzi, it reminds us again that the underlying enabling principle of HBF is the uniform bitmap size of hanzi. Because of the way UNICODE hanzi are ordered, there may be many "holes" with no existing bitmaps. To avoid having hundreds or even thousand pieces of indexes, should we have a "hole" character (bitmap) as a space holder? >3. There's no obvious reason why the size of the char-planes (or the range of > the 2nd byte) should be fixed for all planes. Plus, some space could be saved > if variable sized planes are used. > I have a long response to this point at the end of this message. >4. Providing coding information for every character( like in BDF) would waste >a lot of spaces. Also at least for the exsisting char-sets most of the byte >planes are fix-sized. > >My suggestion is to include an "index" area between the header and the raw bits. >The characters are then divided into some continues blocks according to their >high and low byte ranges. The starting position and length of the bitmaps for >these characters is recorded. Here is an example: > >( header) >BCF92 ( whatever, a magic number) A magic number is fine. >BeginFont > >BeginHeader 34 >Name: BIG5Standard16 >CharSet: BIG5 >Size: 16 16 >... (other infomation) e.g. 1 is black, MSB of first byte is at upper left corner, etc. For our purpose, perhaps it is better to have a fixed interpretation rather than a flexible one as in TIFF. Should we? It seems that most font files do actually use the above interpretation. >EndHeader > >BeginIndex 2 <-- size of the index area, in blocks or bytes 2 means 2 more "lines" (terminated by ) follows ? >A1 F9 40 7E at 1 179428>>><--ranges of 1st and 2nd bytes, at, postition >A1 F9 A1 FE at 179429 447136> of bitmaps >EndIndex I think this is the major technical point we have to consider carefully. Since GB has only one consecutive range for 2nd byte, so there is no problem. However, for BIG5, this arrangement will result in a different "raw bitmap" order from ETEN's and other BIG5 bitmap I know of. What is the tradeoff? > >BeginBitmap 447136 >(447136 raw bytes) >EndBitmap > >EndFont >This is for cclib24: >BeginIndex 1 >A1 F7 A1 FE at 1 588816 >EndIndex See. For cclib24, it is possible to view the new format (HBF) as a header prepended to the original cclib24. For a "lazy" font reader (intended for "old" applications), the only thing that needs to be changed is to scan the offset position of the end of the line "BeginBitmap ...", and add it to whatever offset previously used to locate characters. >This is for cclib16: >BeginIndex 2 >A1 A7 A1 FE at 1 21056 >B0 F7 A1 FE at 21057 237632 >EndIndex >For Chinese16 styled compact BIG5 16( 2nd underfined plane excluded): >BeginIndex 5 >A1 C5 40 7E at 1 ... ( Non-Chinese, Frequently used Chinese) >A1 C5 A1 FE at ... >C6 C6 40 7E at ... >C9 F9 40 7E at ... ( Not-Frequently used Chinese) >C9 F9 A1 FE at ... >EndIndex But now this simple trick can't work with Chinese16. >The subroutines for locating bitmap from a two-byte character code can be >easily standarlized. > >Just an idea. Regards. > >-- Yang, Bo ~{Qn 2*~} Just when I was composing this message, I received the response from ygz: >I'll add that an alternative to > > BeginBitmap 447136 > (447136 raw bytes) > EndBitmap > >may be a pointer to the cclib-like raw bitmap file: > > BitmapFile "cclib24" <-- the pathname of the file where bitmaps > are stored > >In this case, this header can be regarded as a supplement to the >"real" bitmap file. We can reuse all the cclib or ETen font files >by writing a header for each of them. > >Just some comment. > > --ygz I think this is a very practical suggestion which will make more people happy. However, as I just pointed out, the current scheme won't work for "chinese.16": BitmapFile "chinese.16" or other ETEN font files. How about the following change? For GB, cclib24: BeginSecondByteRange 1 A1 FE EndSecondByteRange BeginIndex 1 A1A1 F7FE at 1 588816 EndIndex BitMapFile "cclib24" For BIG5: BeginSecondByteRange 2 40 7E A1 FE EndSecondByteRange BeginIndex 2 A140 C67E at 1 ... ( Non-Chinese, Frequently used Chinese) C940 F97E at .. .. ( Not-Frequently used Chinese) EndIndex BitMapFile "chinese.16" Yes, I do assume that the second byte ranges are fixed, and independent of the first byte. But this is actually the case for GB (A1-FE) BIG5 (40-7E, A1-FE), and Unicode (00-FF) Again, we have a tradeoff between compatability and extensibility. If fixed ranges are not acceptable, is there other solution which can combine the best of both worlds? Best regards, Fung Fung Lee ~{@n7c7e~} ============================================================================ %ARTICLE 4 ============================================================================ >From eric@coeus.ucsd.edu Sun Oct 18 16:39:24 1992 Date: Thu, 15 Oct 92 13:41:10 -0700 From: eric@coeus.ucsd.edu (Bo Yang) To: Ricky.Yeung@Eng.Sun.COM Subject: Re: Re: Some Considerations about the Common Bitmap Chinese Font format Cc: eric@sdphu1.ucsd.edu, lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) writes: >>A1 F9 40 7E at 1 179428>>><--ranges of 1st and 2nd bytes, at, postition >>A1 F9 A1 FE at 179429 447136> of bitmaps >Is the last piece of information (position) redundant? Maybe the number >of characters would be more meaningful than byte offset (which could be >easily calculated with the size information). The reason here is that someone might want have blank spaces or "squeesed" spaces in his font. To explain the later, say in BIG5, the spaces between A3BF and A3FE are not defined. If you REALLY want to save space and don't want to creat a seperated block for A3 plane, you can use: A1-A3 | 40-7E;A1-FE at 1 34000 ( say this number. Non-Chinese) A4-C6 | 40-7E;A1-FE at 31952 129984 ( F.U.Chinese) The bitmaps between 31952 and 34000 are indexed twice. But the first group of indexes are not defined anyway, vola... In fact this kind of practise should be discouraged, but here it's just an example saying that it might be handy sometimes to have them both. Regards. -- Bo Yang ~{Qn 2*~} ============================================================================ %ARTICLE 5 ============================================================================ >From Ricky.Yeung@Eng.Sun.COM Sun Oct 18 16:39:29 1992 Date: Thu, 15 Oct 92 12:35:47 PDT From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: lee@rinconada.stanford.edu Cc: eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@uxmail.ust.hk, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu, ricky.yeung@Eng.Sun.COM In-Reply-To: Fung Fung Lee's message of Wed, 14 Oct 92 21:23:07 -0700 <9210150423.AA05846@rinconada.Stanford.EDU> Subject: Re: Re: Some Considerations about the Common Bitmap Chinese Font format > I agree. The code range information should be explicit as in BDF instead > of being implicit as in cclib. In addition, HBF should be complete, as > M.C. Pong pointed out, in the sense that HBF and BDF should be equivalent > as long as all the bitmaps are of the same size and same other attributes. Yes, it's important. A utility to convert between bdf and hbf without losing information is definitely needed. > Because of the way UNICODE hanzi are ordered, there may be > many "holes" with no existing bitmaps. To avoid having hundreds or even > thousand pieces of indexes, should we have a "hole" character (bitmap) > as a space holder? Agree. >A1 F9 40 7E at 1 179428>>><--ranges of 1st and 2nd bytes, at, postition >A1 F9 A1 FE at 179429 447136> of bitmaps Is the last piece of information (position) redundant? Maybe the number of characters would be more meaningful than byte offset (which could be easily calculated with the size information). > >BeginHeader 34 > >Name: BIG5Standard16 > >CharSet: BIG5 > >Size: 16 16 > >... (other infomation) > > e.g. 1 is black, MSB of first byte is at upper left corner, etc. > For our purpose, perhaps it is better to have a fixed interpretation > rather than a flexible one as in TIFF. > Should we? > It seems that most font files do actually use the above interpretation. I suggest we keep it as simple as possible. For example, it is always 1 is black, MSB of 1st byte is at the upper left corner, etc. We can always write simple filters to convert "non-standard" format to this simple canonical one. -Ricky ~{QnUq8;~} ============================================================================ %ARTICLE 6 ============================================================================ >From eric@coeus.ucsd.edu Sun Oct 18 16:39:34 1992 Date: Thu, 15 Oct 92 13:17:01 -0700 From: eric@coeus.ucsd.edu (Bo Yang) To: lee@rinconada.stanford.edu Subject: Re: Some Considerations about the Common Bitmap Chinese Font format Cc: eric@sdphu1.ucsd.edu, lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu ygz writes: >I'll add that an alternative to > > BeginBitmap 447136 > (447136 raw bytes) > EndBitmap > >may be a pointer to the cclib-like raw bitmap file: > > BitmapFile "cclib24" <-- the pathname of the file where bitmaps > are stored > >In this case, this header can be regarded as a supplement to the >"real" bitmap file. We can reuse all the cclib or ETen font files >by writing a header for each of them. > >Just some comment. > > --ygz I think this is very good idea. However it might be handy to have a flag in the header to indicate if Bitmap block or BitmapFile is used. Lee writes: >How about the following change? >For GB, cclib24: >BeginSecondByteRange 1 >A1 FE >EndSecondByteRange >BeginIndex 1 >A1A1 F7FE at 1 588816 >EndIndex >BitMapFile "cclib24" >For BIG5: >BeginSecondByteRange 2 >40 7E >A1 FE >EndSecondByteRange >BeginIndex 2 >A140 C67E at 1 ... ( Non-Chinese, Frequently used Chinese) >C940 F97E at .. .. ( Not-Frequently used Chinese) >EndIndex >BitMapFile "chinese.16" >Yes, I do assume that the second byte ranges are fixed, and independent >of the first byte. But this is actually the case for >GB (A1-FE) >BIG5 (40-7E, A1-FE), and >Unicode (00-FF) >Again, we have a tradeoff between compatability and extensibility. >If fixed ranges are not acceptable, is there other solution which >can combine the best of both worlds? >Fung Fung Lee ~{@n7c7e~} How about non-continues blocks: BeginIndex 4 A1-C5|40-7E;A1-FE at 1... C6|40-7E at ... ... C9-F8|40-7E;A1-FE at ... ... F9|40-7E at ... ... EndIndex BitmapFile "chinese.16" or BeginIndex 1 A1-A7;B0-F7|A1-FE at 1 ... EndIndex BitmapFile "cclib.16" Now we can have both. The question is, will the algorithms for decoding these index information and then those used to map the characters to bitmaps be less efficient, compared to those used with fix-ranged index as proposed by Lee? If only we don't have to give up simplicity for extensibility... I'm still not sure how the header and index will be put into use in the application programs. Will the subroutines actually detect every bit of information contained in the header or they only recognize their own fonts and reject the un-formiliar ones and then goes into their own subroutines designed for the specific fonts, so most of the header stuff will be valuable only for human eyes? :-) I'm sure someones out there are quite experinced on this... Best regards. -- Bo Yang ~{Qn 2*~} ============================================================================ %ARTICLE 7 ============================================================================ >From mcpong@uxmail.ust.hk Sun Oct 18 16:39:44 1992 Date: Sat, 17 Oct 92 16:58:09 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: eric@sdphu1.ucsd.edu Subject: Common Hanzi Bitmap Format (HBF) Cc: lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu Let me summarize a bit, and hope that we can be approaching the final HBF, and then someone will implement the various conversion programs :-). The following uses the formal notation Extended Backus-Normal Form (EBNF) to describe a HBF file. The left-hand-side can generate "items" on the right-hand side of each "production rule". A rule is terminated by the symbol "." . "{ 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 can occur. "( item1 item2 )" is to group item1 and item2 to become another "item". 'literal' is the literal string that should appear as it is (without the single-quote) in the rule. (In formal language terminology, "item" will be "token", which is either a "terminal" or "non-terminal" symbol. I like to use lower case letter to start a terminal symbol and upper case letter to start a non-terminal symbol.) HBF ::= Header Body. Header ::= FontName { FontAttribute } . FontName ::= 'FontName' ':' nameOfFont . FontAttribute ::= BitMapSizeAttribute | xxxAttribute | yyyAttribute | ... . /* Yet to be detailed. * * Attributes like the X BDF * -- any one complete the sub-rules for all FontAttribute? :-) */ BitMapSizeAttribute ::= 'BitmapSize' ':' numberOfBitForWidth numberOfBitForWidth. /******/ Body ::= RawBitmapFile IndexToCharSection . RawBitmapFile ::= 'Raw' 'bitmap' 'filename' ':' nameOfRawBitmapFile . IndexToCharSection ::= 'BEGININDEX' { IndexRange } 'ENDINDEX' . /* ^^^^^^^^^^ such words used to make HBF file * more readable. */ IndexRange ::= HCByteRange HCByteRange 'at' CharRange. HCByteRange ::= twoDigitHexadecmialNumber '-' twoDigitHexadecmialNumber . CharRange ::= decimalNumber '-' decimalNumber . /* HC means internal hanzi-code. * The i-th RCByteRange means the valid range of values for * the i-th byte of RC. * * CharRange means the beginning and ending Chinese Char position * in the RawBitmapFile. * -- N.B. The Char position is used, instead of byte offset; * because the char position eventually may be common * across different font file for the same HC, say GB/Big5. * -- The byte offset can be easily calculated. * * e.g. a valid IndexRange for cclib24 is * A1-F7 A1-FE at 1-8178 * * e.g. valid IndexRange(s) for cclib16 is * A1-A7 A1-FE at 1-658 * B0-F7 A1-FE at 659-7426 */ ================ Any comments? m c pong ============================================================================ %ARTICLE 8 ============================================================================ >From lee Sat Jan 30 17:38:01 1993 Date: Sun, 18 Oct 92 18:52:47 -0700 From: lee (Fung Fung Lee) To: ryeung@hk.eng.sun.com, eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@uxmail.ust.hk, william@anucsd.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu, lee@umunhum.stanford.edu Subject: HBF (Hanzi Bitmap Format) I am glad to see M.C. Pong's description of the syntax of the current proposal of HBF in EBNF. However, as I pointed out in previous article, there are problems with the current proposal. Taking into consideration of Bo Yang's response to my last proposal, I have come up with some new suggestions. There are two parts in this article. Part I. Three Index Range Encoding Schemes ------------------------------------------ As we may have observed, almost any index design will work well with GB due to its simplicity. However, there are problems with BIG5 with the current index encoding. regions of BIG5 codes BIG5 coding --------------------- ----------------- 1. symbols (408) 0xa140 -- 0xa3bf 2. Undefined 0xa3c0 -- 0xa3fe 3. Frequent (5401) 0xa440 -- 0xc67e 4. Undefined 0xc6a1 -- 0xc8fe 5. Non-frequent (7652) 0xc940 -- 0xf9d5 6. Undefined 0xf9d6 -- 0xf9fe Suppose the BIG5-ordered raw bitmap file "foo16" contains only the bitmaps of hanzi in regions 1, 3, and 5. The blocks of bytes representing the bitmap of the Han characters is packed tightly so that the ordering relation is the same as that of the internal code. This is not only a "natural" ordering for most people, but also common in actual practice, such as ETEN's format. For many practical reasons, HBF must provide flexible and efficient indexing mechanisms so that it works with as many current formats as possible. Users can then use their own bitmap files (without change), even if they are not in the public domain!! For this type of format, the current proposal (A) will need about 200 indices: (for the moment, the "at" stuff is not included) BeginIndex A1-A1 40-7E A1-A1 A1-FE A2-A2 40-7E A2-A2 A1-7E A3-A3 40-FE A3-A3 A1-BF A4-A4 40-7E . . . F9-F9 A1-D5 EndIndex Let's consider another proposal (B) for the same example: BeginIndex A1-A2 40-7E A1-FE A3-A3 40-7E A1-BF A4-C5 40-7E A1-FE C6-C6 40-7E C9-F8 40-7E A1-FE F9-F9 40-7E A1-D5 EndIndex To further simplify, we have yet another proposal (C) for the same example: BeginIndex A140-A3BF 40-7E A1-FE A440-C67E 40-7E A1-FE C940-F9D5 40-7E A1-FE EndIndex Note how simple and similar this format is to the way the region table is orginally described! Let's take a look at other examples using proposal C For cclib16: BeginIndex A1A1-A7FE A1-FE B0A1-F7FE A1-FE EndIndex For Unicode: BeginIndex 4E00-FA2D 00-FF EndIndex Well, which of the 3 proposals (A, B, C) do you guys prefer? Why? Part II What should "at" point to ---------------------------------- Given any of the 3 proposals above, there is sufficient information to compute the (relative) character order or position, but there is not necessarily sufficient information to compute the "byte offset". For example, in "chinese.16", there is copyright information and other stuff before the raw bitmaps; in Macintosh's Chinese bitmap files, there are even their proprietary index information! There are many technical and non-technical reasons that we do not want to change those bitmap files, but can still use them. Hence, we need pointers to the actual locations to the bitmaps! Suppose in the BIG5-ordered raw bitmap file foo16, the bitmaps of the codes A140, A440, C940 start at byte offsets 256, 24000, 186000 (I just made up the numbers), then we have for proposal C: BeginIndex A140-A3BF 40-7E A1-FE at 256 A440-C67E 40-7E A1-FE at 24000 C940-F9D5 40-7E A1-FE at 186000 EndIndex -FFL ============================================================================ %ARTICLE 9 ============================================================================ >From Ricky.Yeung@Eng.Sun.COM Sat Jan 30 17:38:36 1993 Date: Wed, 28 Oct 92 23:40:13 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: lee@umunhum.stanford.edu Cc: eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@usthk.bitnet, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu, Ricky.Yeung@Sun.COM In-Reply-To: Fung Fung Lee's message of Sun, 18 Oct 92 18:52:47 -0700 <9210190152.AA24433@umunhum.Stanford.EDU> Subject: Re: HBF (Hanzi Bitmap Format) > Well, which of the 3 proposals (A, B, C) do you guys prefer? Why? I would prefer proposal C for its simplicity. How about the others? > Part II What should "at" point to > ---------------------------------- > > Given any of the 3 proposals above, there is sufficient > information to compute the (relative) character order or > position, but there is not necessarily sufficient information > to compute the "byte offset". For example, in "chinese.16", > there is copyright information and other stuff before the raw > bitmaps; in Macintosh's Chinese bitmap files, there are even > their proprietary index information! There are many > technical and non-technical reasons that we do not want to > change those bitmap files, but can still use them. Hence, we > need pointers to the actual locations to the bitmaps! Agreed. So far we've had a pretty constructive discussion and generated some interesting ideas. In order not to let this exchange slip away, I'd suggest the following plan to work toward a fruitful result: 1. First we need to come to consensus on the format. Make sure everyone is satisfied because you'll be the "user" of BHF. Without your (the developers') support, BHF is meaningless. 2. Then we need to recruit people to co-author a draft document for HBF (a specification document similar to the HZ specification). 3. Make the draft publicly available on the network and solicit for comments. 4. Finalize the document. 5. Solicit for sample implementation (maybe a perfect homework project for M. C. Pong's students :-)). 6. Make the final document and sample implementation publicly available. 7. Use the library (developed in step 5) in your software. The minimum participation requested are steps 1 and 7. How does it sound to you? If you guys like the plan, I (any volunteer?) can coordinate its execution. -Ricky ============================================================================ %ARTICLE 10 ============================================================================ >From ygz@cs.purdue.edu Sat Jan 30 17:38:55 1993 To: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Cc: lee@umunhum.stanford.edu, eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@uxmail.ust.hk, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, Ricky.Yeung@Sun.COM Subject: Re: HBF (Hanzi Bitmap Format) In-Reply-To: Your message of Wed, 28 Oct 92 23:40:13 -0800. <9210290740.AA15927@hk.Eng.Sun.COM> Date: Sat, 31 Oct 92 13:08:57 EST From: ygz@cs.purdue.edu (Yongguang Zhang) > So far we've had a pretty constructive discussion and generated some > interesting ideas. In order not to let this exchange slip away, I'd > suggest the following plan to work toward a fruitful result: > > 1. First we need to come to consensus on the format. Make sure everyone > is satisfied because you'll be the "user" of BHF. Without your > (the developers') support, BHF is meaningless. > > 2. Then we need to recruit people to co-author a draft document for HBF > (a specification document similar to the HZ specification). > > 3. Make the draft publicly available on the network and solicit for > comments. > > 4. Finalize the document. > > 5. Solicit for sample implementation (maybe a perfect homework project > for M. C. Pong's students :-)). > > 6. Make the final document and sample implementation publicly available. > > 7. Use the library (developed in step 5) in your software. > > The minimum participation requested are steps 1 and 7. How does it > sound to you? If you guys like the plan, I (any volunteer?) can > coordinate its execution. > > -Ricky I support the format and will use it in writing programs that involve hanzi bitmap files (although most of the time I work on the X platform). F.F. Lee's (C) scheme sounds good to me. Plus M.C.Pong's BNF definition, we can start to do something (a document first). --ygz ============================================================================ %ARTICLE 11 ============================================================================ >From mcpong@uxmail.ust.hk Sat Jan 30 17:39:03 1993 Date: Mon, 2 Nov 92 09:20:16 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: eric@sdphu1.ucsd.edu, lai@apple.com, lee@umunhum.stanford.edu, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu Subject: Plan for HBF > 1. First we need to come to consensus on the format. Make sure everyone > is satisfied because you'll be the "user" of BHF. Without your > (the developers') support, BHF is meaningless. > ... > > 7. Use the library (developed in step 5) in your software. > > The minimum participation requested are steps 1 and 7. How does it > sound to you? If you guys like the plan, I (any volunteer?) can > coordinate its execution. > > -Ricky F.F.Lee's scheme C is concise and doable. I can base further work on this proposal. > I support the format and will use it in writing programs that involve > hanzi bitmap files (although most of the time I work on the X platform). > F.F. Lee's (C) scheme sounds good to me. Plus M.C.Pong's BNF definition, > we can start to do something (a document first). > > --ygz Another point: ISO10646 is coming. It consists of only 2-bytes & 4-bytes codes. CJKv2.0 is part of the 2-byte code set. (Don't know if there's any 4-byte code defined; probably not [yet]. Also don't know how to distinguish 2- & 4- byte codes.) Anyway, Unicode is the 2-byte code subset of ISO10646. In defining the final HBF format, we should take into account how to define 4-byte code. BTW, if anyone is interested in knowing ISO10646, a company in HK & an organization in China has jointly published the ISO10646 Draft International Standard (DIS). I found it in Commercial Press bookshop & costs US$200. I suspect that based on the Unicode document is good enough for our purpose at the moment. I can propose a project for a final-year undergrad to do a parser for HBF & a sample implementation; but it won't start until 9/1993 when HKUST has the 1st batch of final-year undergrad. mcpong P.S. FYI Last week, I attended the International Conference on Chinese Information Processing (ICCIP) 1992 held in Beijing. ------ As printed char recognition had been quite successful already, many recent research projects/products in the Mainland China are on online or offline handwritten char recognition. 300 delegates attended ICCIP'92, with about 60 from abroad, mostly from Taiwan. Taiwanese companies are eagar to acquire technologies from Mainland Chinese researchers and further develop/package to sell. ------ Another trends already set is to use a library of Chinese phrases (ciku) to help input and recognition. All systems in the exhibition are PC based. Some of them have incorporated the prefix-matching scheme, mostly based on pinyin. (E.g., jsj, or j1sh'j will give as one of the choices.) ------ There are still some "new" input methods. There's no demo in Unix based systems. ------ ============================================================================ %ARTICLE 12 ============================================================================ >From lee Sat Jan 30 17:39:23 1993 Date: Wed, 11 Nov 92 15:46:46 -0800 From: lee (Fung Fung Lee) To: mcpong@uxmail.ust.hk Cc: eric@sdphu1.ucsd.edu, lai@apple.com, mcpong@uxmail.ust.hk, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu In-Reply-To: Dr. PONG Man Chi's message of Mon, 2 Nov 92 09:20:16 HKT <9211020120.AA10636@uxmail.ust.hk> Subject: Re: Plan for HBF First, thanks for M.C. Pong's notes about the ICCIP conference. It seems to me that there is/will be a successful unification of Unicode and ISO DIS 10646, so that the (Han) character repertoires and encoding assignments of both standards will be identical. >In defining the final HBF format, we should take into account how to >define 4-byte code. If that is true, then the simple extension may be, for example: xxxx4E00-xxxxFA2D 00-FF ; for ISO DIS 10646 instead of 4E00-FA2D 00-FF ; for Unicode It seems that the trend is to use the full code range (00-FF) for the least significant byte, instead of the partial ranges as in GB or BIG5, so that the need for more flexible indices will actually diminish! Anyway, it seems a bit pre-mature now to further consider the ramifications of ISO DIS 10646 on HBF. I think we can be content if HBF solves the problem for GB, BIG5, and Unicode. ============================================================================ %ARTICLE 13 ============================================================================ >From mcpong@uxmail.ust.hk Sat Jan 30 17:39:38 1993 Date: Thu, 12 Nov 92 08:57:50 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: lee@rinconada.stanford.edu, mcpong@uxmail.ust.hk Subject: Re: Plan for HBF Cc: eric@sdphu1.ucsd.edu, lai@apple.com, ryeung@hk.eng.sun.com, william@dubhe.anu.edu.au, yawei@bronze.ucs.indiana.edu, ygz@cs.purdue.edu > From lee@rinconada.Stanford.EDU Thu Nov 12 07:46:31 1992 > > It seems to me that there is/will be a successful unification of Unicode > and ISO DIS 10646, so that the (Han) character repertoires > and encoding assignments of both standards will be identical. There will be unification of CJK char set (called something like Ideographic Char Set in ISO10646). Not only "it seems" :-) > >In defining the final HBF format, we should take into account how to > >define 4-byte code. > > If that is true, then the simple extension may be, for example: > xxxx4E00-xxxxFA2D 00-FF ; for ISO DIS 10646 > instead of > 4E00-FA2D 00-FF ; for Unicode > > It seems that the trend is to use the full code range (00-FF) for the > least significant byte, instead of the partial ranges as in GB or BIG5, > so that the need for more flexible indices will actually diminish! > Anyway, it seems a bit pre-mature now to further consider the ramifications > of ISO DIS 10646 on HBF. I think we can be content if HBF solves the > problem for GB, BIG5, and Unicode. In the meantime, we may consider 2-byte encoding first. We can introduce a keyword attribute, say, 'ENCODING:' ( 'GB2312' | 'BIG5' | 'UNICODE' | 'ISO10646' ) . The case for ISO10646 can be handled later. We need someone to really write down a draft of the HBF specification syntax. I am too busy to do it in 1992 (may be not until summer'93); though, I am willing to review any draft. mcpong ======================================================================== From CAI@neurophys.wisc.edu Sun Jan 31 15:36:21 1993 Return-Path: Date: Sun, 31 Jan 93 15:07 CST From: CAI@neurophys.wisc.edu Subject: HBF font format To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO I did not take part in the discussion of Oct. 1992. From FFL's summary, I think the discussion was quite fruitful. The points summarized by FFL and that of Ni's could make a very good fundation for a draft. Here are some of my thoughts. I. Scope HBF (Hanzi Bitmap Format) includes GB, BIG5, Unicode, etc. At present, we can focus on GB and Big5. II. Name protocol In general, I support the idea proposed by Ni. Here is a modified one. ABCDnn.HBF A - GB (G), Big5 (B), Unicode (U), JIS (J), etc. B - Jinati, Fanti, ASCII, or user defined. C - font style, i.e. Song, Hei, etc. D - different variations nn - font size HBF - indicate Hanzi Bitmap Format An alternative for this name protocal is ****.HBF There no restriction what **** stands for and its length. The information about the fonts is given in the header. III. Structure and Indexing HBF font should have a header followed by the bitmap information itself. The header may contain any information other than bitmap info itself. But it MUST contain some index information which tells how the bitmap information is organized. Based on proposal C in FFL: AAAA-BBBB aa-bb cc-dd WxH at nnnn or AAAA-BBBB aa-bb WxH at nnnn AAAA-BBBB - the continuously encoded global sections aa-bb and cc-dd - the actually encoded area as defined by the lower half of the address in the global sections WxH - the size (width x height) nnnn - the exact address in the font the bitmap information begins in these sections. e.g. for the Big 5 font in FFL's example BeginIndex A140-A3BF 40-7E A1-FE 24x24 at 1234 A440-C67E 40-7E A1-FE 24x24 at 4567 C940-F9D5 40-7E A1-FE 24x24 at 6789 EndIndex for cclib16: BeginIndex A1A1-A7FE A1-FE 16x16 at 1234 B0A1-F7FE A1-FE 16x16 at 5678 EndIndex Note 1. WxH allows encoding of non-square characters, such as the ASCII chars in some fonts, e.g. cclib.j24. 2. There is no need to encode those empty sections. This is especially important for Big5 and Unicode because there are a lot of undefined sections. However, if one choose to encode those empty sections, the font can still be recognized by application programs. 3. If some day one fills those empty sections, the old program can still recognize and be able to use the new fonts. (This is why D is suggested in the name protocal) Final comment: It was suggested in Ni's proposal that the sympol should be separated from the Chinese characters. I think this is an good idea only if fonts with different styles share the same symbol. I do not know if it is the case. Otherwise it would be better not to seperate the symbol sections. Regards, Yidao =========================== From simpson@math.psu.edu Thu Feb 11 20:49:50 1993 Return-Path: From: Stephen G Simpson Date: Thu, 11 Feb 93 21:38:40 -0500 To: soft-authors@ifcss.org Subject: HBF standard ? Status: RO Greetings, About the HBF or "standardization_chinese_bitmap_fonts" discussion group. I have not heard anything from the group recently. It appears that a pretty good consensus has emerged, but nobody has time to sit down and write the detailed document describing the proposed standard. Would someone care to give at least a sketch or summary of the proposed standard? Hopefully this summary could serve as a working document for software authors who are in need of guidance. For example, I am writing a small MS-DOS educational program, tentatively called FLASH, for use by people like me, i.e. English-speaking students of the Chinese language. The program including source code will be freely available. The purpose of the program is to display flashcards for Chinese character drill, using 24x24 bitmaps for both GB/simplified and BIG5/traditional characters. Consider my perspective as a software author. I am willing to rewrite FLASH to conform to any reasonable standard for bitmaps, but I am waiting for the standard to emerge. If the standard does not emerge by the time I am ready to release FLASH, I guess I will simply distribute it with the bitmaps that I happen to be using. This means that FLASH.ZIP will be on the order of 500 to 1200 K, instead of 60 K. One problem I have is that the traditional character bitmaps that I am using are derived from ET's, so maybe I am not allowed to distribute them freely. One possible solution is to distribute FLASH without traditional character bitmaps, but in a form that can be used with ET's bitmaps. The user of FLASH would then have to buy his own copy of ET. In addition to the obvious disadvantages, there is also the possibility that ET Inc. could change its font format, so that the needed bitmaps will no longer be easily available. There are also advantages -- people who already have ET could use FLASH with no need for additional fonts. Any comments? Once again this points up the need for a set of public domain 24x24 traditional character bitmaps. But, until such bitmaps appear, the ET bitmaps are the closest approximation. Therefore, one suggestion I have for the HBF group is that the ET bitmaps should be somehow incorporated into the proposed standard. Best wishes, Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20@PSUVM FAX: +1 814 865-3735 From lee@fritter.Stanford.EDU Thu Feb 11 21:38:02 1993 Return-Path: Date: Thu, 11 Feb 93 19:26:34 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Thu, 11 Feb 93 21:38:40 -0500 <9302120238.AA21378@boole.math.psu.edu> Subject: Re: HBF standard ? Status: O >From: Stephen G Simpson >Would someone care to give at least a sketch or summary of the >proposed standard? Hopefully this summary could serve as a working >document for software authors who are in need of guidance. I think you can find the various proposals in previous archived messages on ifcss.org (Xiaofei, where are they exactly?) >Once again this points up the need for a set of public domain 24x24 >traditional character bitmaps. But, until such bitmaps appear, the ET >bitmaps are the closest approximation. Therefore, one suggestion I >have for the HBF group is that the ET bitmaps should be somehow >incorporated into the proposed standard. Could Mr. Stephen G. Simpson describe the ET bitmap font file format? Could someone also describe the CCDOS (or other popular Chinese DOS) bitmap font file format? Fung F. Lee From simpson@math.psu.edu Fri Feb 12 10:52:42 1993 Return-Path: From: Stephen G Simpson Date: Fri, 12 Feb 93 11:39:55 -0500 To: soft-authors@ifcss.org Subject: ET 24x24 bitmap font format Status: O I wrote: > There is need for a set of public domain 24x24 > traditional character bitmaps. But, until such bitmaps appear, the ET > bitmaps are the closest approximation. Therefore, one suggestion I > have for the HBF group is that the ET bitmaps should be somehow > incorporated into the proposed standard. F. F. Lee replied: > Could Mr. Stephen G. Simpson describe the ET bitmap font file format? Yes, I can do that. The 24x24 ET 2.03 bitmap files are as follows: ASCFONT.24 12288 7-01-90 SPCFONT.24 29376 7-01-90 SPCFSUPP.24 26280 7-01-90 STDFONT.24 942768 7-01-90 STDFONT.24K 942768 7-01-90 STDFONT.24L 942768 7-01-90 These files (except ASCFONT.24) contain naked 24x24 bitmaps. Each bitmap consists of 72 bytes, i.e. 24*24 bits. The bits within a bitmap are in row major order, upper left to lower right. STDFONT.24 contains Ming-style bitmaps, while STDFONT.24K and STDFONT.24L contain Kai and Li style bitmaps respectively. The bitmaps are further described in a posting by Urs Widmer to CCNET some time ago: From: Urs Widmer Date: Tue, 21 May 91 22:24:27 GMT Answer to a email-question as to the coding structure of the ET-fontfiles: Here the informations for the files with version 2.0: --------------------------------------------------------------------------- Fontname bytes lines char extent (QU / WEI) Contents per per no in BIG-5 coding line charac begin end --------------------------------------------------------------------------- ASCFONT.24 2 24 256 IBM 8-bit-ASCII --------------------------------------------------------------------------- SPCFONT.24 3 24 407 01/001 03/094 Standard BIG-5 (non Chinese in BIG-5) --------------------------------------------------------------------------- SPCFSUPP.24 3 24 365 38/064 40/114 ET-supplement to BIG-5 (Japanese Russian etc) --------------------------------------------------------------------------- STDFONT.24 3 24 5401 04/001 38/063 frequent BIG-5 characters 7651 41/001 89/115 less frequent BIG-5 char. 42 89/116 89/157 ET-suppl. to BIG-5 (8 Hanzi, rest graphics) (Total: 13094) --------------------------------------------------------------------------- Notice: The BIG-5 code occupies the QUs from 1 to 89 (94 would be possible acording to the coding structure.) Each QU contains 157 Positions (WEIs) or each QU is an array of 157 elements. Important notice: In the STDFONT.24 the less frequent character follow closely the frequent ones, though in the coding scheme in BIG-5 there is a "hole". This "hole" is (partly) filled by the SPCFSUPP.24-font, which contains useful characters, which are not contained in standard BIG-5 as Japanese Hiragana and Katakana and some other stuff which is contained in the Qu 1-10 of GB 2312. From simpson@math.psu.edu Sat Feb 13 22:31:59 1993 Return-Path: From: Stephen G Simpson Date: Sat, 13 Feb 93 23:24:09 -0500 To: soft-authors@ifcss.org Subject: ET bitmap font files and character codes Status: O Here is a better description of the ET bitmap font files and character codes. I extracted this information by poking around in my own copy of ET, Version 2.00.03. I don't know whether this information is correct for other versions of ET. The ET bitmap font files are as follows: ASCFONT.15 3840 7-01-90 ASCFONT.24 12288 7-01-90 SPCFONT.15 12240 7-01-90 SPCFONT.24 29376 7-01-90 SPCFSUPP.15 10950 7-01-90 SPCFSUPP.24 26280 7-01-90 STDFONT1.15 32490 7-01-90 STDFONTS.15 360330 7-01-90 STDFONT.24 942768 7-01-90 STDFONT.24K 942768 STDFONT.24L 942768 To this list it is convenient to add: STDFONT.15 392820 There is no actual file called STDFONT.15, but it could be created by concatenating STDFONT1.15 followed by STDFONTS.15, and its size would then be 32490 + 360330 = 392820 bytes. The description below will be given in terms of STDFONT.15 rather than STDFONT1.15 and STDFONTS.15. The *.15 files consist of 30 byte 16x15 bitmaps, except for ASCFONT.15, which consists of 15 byte 8x15 bitmaps. The *.24 files consist of 72 byte 24x24 bitmaps, except for ASCFONT.24 which consists of 48 byte 16x24 bitmaps. The bits within a bitmap are always in row major order, i.e. the first row followed by the second row followed by ..., and from left to right within each row. STDFONT.24, STDFONT.24K and STDFONT.24L are identical except that they contain Chinese character bitmaps in Ming, Kai, and Li styles respectively. The description below will be given in terms of STDFONT.24 but it applies equally to STDFONT.24K and STDFONT.24L. A 1-byte code consists of one byte. The possible values of the byte are 00 through FF, i.e. 256 possibilities. Codes 00 through FF are used for the 256 bitmaps in ASCFONT.15 (= 256 * 15 = 3840 bytes) and in ASCFONT.24 (= 256 * 48 = 12288 bytes). These 256 bitmaps consist of the IBM PC "extended ASCII" character set. A 2-byte code consists of two bytes. The possible values of the first byte are A1 through FE, i.e. 94 possibilities. The possible values of the second byte are 40 through 7E and A1 through FE, i.e. 63 + 94 = 157 possibilities. Codes A140 through A3BF (2 * 157 + 94 = 408 codes) are used for the 408 bitmaps in SPCFONT.15 (= 408 * 30 = 12240 bytes) and in SPCFONT.24 (= 408 * 72 = 29376 bytes). These 408 bitmaps include punctuation marks, graphics characters, special symbols, Roman numerals, Arabic numerals, the Roman and Greek alphabets, and the Bopomofo syllabary. Codes A3C0 through A3FE (63 codes) are unused. Codes A440 through C67E (34 * 157 + 63 = 5401 codes) are used for the first 5401 bitmaps in STDFONT.15 (= 5401 * 30 = 162030 bytes) and in STDFONT.24 (= 5401 * 72 = 388872 bytes). See footnote below. These 5401 bitmaps consist of the 5401 Big-5 "frequent use" Chinese characters. Codes C6A1 through C8D3 (94 + 157 + 114 = 365 codes) are used for the 365 bitmaps in SPCFSUPP.15 (= 365 * 30 = 10950 bytes) and in SPCFSUPP.24 (= 365 * 72 = 26280 bytes). These 365 bitmaps include some additional numerals and special symbols, the Japanese Hiragana and Katakana syllabaries, and the Russian alphabet. Codes C8D4 through C8FE (43 codes) are unused. Codes C940 through F97E (49 * 157 = 7693 codes) are used for the remaining 7693 bitmaps in STDFONT.15 (= 7693 * 30 = 230790 bytes) and in STDFONT.24 (= 7693 * 72 = 553896 bytes). See footnote below. These 7693 bitmaps consist of the 7652 Big-5 "less frequent use" Chinese characters, followed by 7 additional Chinese characters and 41 additional graphics characters. Codes FA40 through FEFE (785 codes) are unused. Footnote: The size of STDFONT.15 is (5401 + 7693) * 30 = 162030 + 230790 = 392820 bytes. The size of STDFONT.24 is (5401 + 7693) * 72 = 388872 + 553896 = 942768 bytes. Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20@PSUVM FAX: +1 814 865-3735 February 13, 1993 From lee@fritter.Stanford.EDU Sun Feb 14 23:34:26 1993 Return-Path: Date: Sun, 14 Feb 93 21:25:20 -0800 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: HBF Specification Version 0.8 (Draft) Status: O HBF Specification Version 0.8 (Draft) Dear software authors: Thanks for the information provided by Stephen G. Simpson on ETEN font file format. I was able to generate some sample .hbf files for those fonts (see et-kai24fb.hbf, et-16x24.hbf). Since no one had responded to my request about CCLIB font file format, I decided to give examples based on the files Beijing*.* used by hz2ps. Hopefully, someone else will post similar example .hbf files describing the various CCLIB (or its derivatives) font files stored on ifcss.org: software/fonts. The syntax of HBF was pretty much borrowed from X window's BDF. Indeed, the intention is to make the conversion between HBF and BDF perfect under the special case of fixed-pitch fonts. Many of the 19 properties included may not be immediately useful to many programs, but let's keep them there for other (future) programs. Particular attention was paid to the syntax so that parsing will be easy by using C's sscanf(). Numbers can be expressed in any base understandable by %i conversion. Structures of the same types (bitmaps, segments, ranges) can be allocated once and for all in one pass of the .bdf file. Will Stephen or someone else be interested in implementing a set of library functions, such as loading a HBF file, and providing the bitmap (pointer) corresponding to a (16-bit GB/BIG5) code? It will then be fairly easy for existing programs to use the new format. Once HBF is supported by programs, the user may easily edit his own custom version of .hbf files to eliminate redundant font files, add user-defined characters, and use privately-owned font files without modifying the source code and juggling the bitmaps. Any volunteers to carry forward the project? Unfortunately I'm running out of spare time in the coming months. :-| Xiaofei, can we count on you to lead the discussion from now on? Best regards, Fung F. Lee lee@umunhum.stanford.edu P.S. The effort in standardizing the naming convention of font files is helpful, but whichever convention is chosen can be accomodated in HBF :-) --- the power of indirection. Five examples demonstrating the format and flexibility of the proposed Hanzi Bitmap Format (HBF) version 0.8 ============================================================================== STARTFONT HBF 0.8 COMMENT COMMENT cc-song16jg.hbf (or cc-s16jg.hbf to fit in DOS' limitation) COMMENT COMMENT The naming convention of a .hbf file is NOT part of the HBF standard. COMMENT The above name for this file is just an example. COMMENT If there is no limitation on the name of a file name, an COMMENT alternative name could be :-) COMMENT "-CC-Song-Medium-R-Normal-Jian-16-120-100-100-M-160-GB2312.80-1.hbf" COMMENT COMMENT This is only a sample notice. COMMENT COMMENT Source: CC Corp. COMMENT COMMENT Permission to use, copy, modify, and distribute this software and COMMENT its documentation for any purpose and without fee is hereby granted, COMMENT provided that the above copyright notices appear in all copies and COMMENT that both those copyright notices and this permission notice appear COMMENT in supporting documentation, and that the name of CC Corp. COMMENT not be used in advertising or publicity pertaining to distribution COMMENT of the software without specific, written prior permission. COMMENT CC Corp. makes no representations about the suitability of this COMMENT software for any purpose. It is provided "as is" without express COMMENT or implied warranty. COMMENT FONT -CC-Song-Medium-R-Normal-Jian-16-120-100-100-M-160-GB2312.80-1 SIZE 16 100 100 COMMENT FONTBOUNDINGBOX FONTBOUNDINGBOX 16 16 0 -2 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "CC" FAMILY_NAME "Song" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "Jian" PIXEL_SIZE 16 POINT_SIZE 120 RESOLUTION_X 100 RESOLUTION_Y 100 SPACING "M" AVERAGE_WIDTH 160 CHARSET_REGISTRY "GB2312-80" CHARSET_ENCODING "1" DEFAULT_CHAR 0xA1A1 FONT_DESCENT 2 FONT_ASCENT 14 COPYRIGHT "Copyright (c) 1993 CC Corp. Permission to copy and use is granted." COMMENT COMMENT All these properties are present in X window's BDF. COMMENT ENDPROPERTIES COMMENT Total number of characters (hanzi) in all the bitmap font files CHARS 8173 COMMENT START_LOW_BYTE_RANGES 1 LOW_BYTE_RANGE 0xA1-0xFE END_LOW_BYTE_RANGES COMMENT COMMENT The pathnames of the bitmap files are relative to the .hbf file. COMMENT For maximum portability across different operating systems, COMMENT this .hbf file and the bitmap files should be in the same directory. COMMENT COMMENT segment line format: - "" COMMENT points to the first byte of the bitmap of COMMENT In general, the offset is greater than 0. COMMENT Bitmaps of consecutive characters per range are in sequence. COMMENT COMMENT The segments should be non-overlapping and listed in increasing COMMENT code order. COMMENT COMMENT For maximum portability, it is not recommended to have COMMENT be this same .hbf file, because of problems like . COMMENT STARTSEGMENTS 3 COMMENT Non-hanzi symbols (1410 chars) with many unused codes SEGMENT 0xA1A1-0xAFFE "Beijing16.0" 0 COMMENT Frequently-used hanzi (3755 chars) SEGMENT 0xB0A1-0xD7F9 "Beijing16.1" 0 COMMENT 0xD7FA-0xD7FE (5 chars) unused COMMENT Less-frequently-used hanzi (3008 chars) SEGMENT 0xD8A1-0xF7FE "Beijing16.2" 0 COMMENT User-defined hanzi/symbols (suggested range) (282 chars) COMMENT 0xF8A1-0xFAFE "myfont.16" 0 ENDSEGMENTS COMMENT As for the raw bitmap itself, HBF assumes the common convention COMMENT used by CCDOS, ETEN, Macintosh Chinese OS, X window's BDF: COMMENT the most significant bit of the first byte is the upper-left bit COMMENT of the characer image; the least significant bit of the last byte COMMENT is the lower-right bit of the image. The scanning order is from top COMMENT to bottom, and from left to right. Black is 1, white is 0. COMMENT The number of bytes per image is exactly equal to (W x H / 8) bytes, COMMENT where W (H) is the width (height) of the image. ENDFONT ============================================================================== STARTFONT HBF 0.8 COMMENT COMMENT cc-song24jg.hbf (cc-s24jg.hbf) COMMENT FONT -CC-Song-Medium-R-Normal-Jian-24-180-100-100-M-240-GB2312.80-1 SIZE 24 100 100 FONTBOUNDINGBOX 24 24 0 -3 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "CC" FAMILY_NAME "Song" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "Jian" PIXEL_SIZE 24 POINT_SIZE 180 RESOLUTION_X 100 RESOLUTION_Y 100 SPACING "M" AVERAGE_WIDTH 240 CHARSET_REGISTRY "GB2312-80" CHARSET_ENCODING "1" DEFAULT_CHAR 0xA1A1 FONT_DESCENT 3 FONT_ASCENT 21 COPYRIGHT "Copyright (c) 1993 CC Corp. Permission to copy and use is granted." ENDPROPERTIES CHARS 8173 START_LOW_BYTE_RANGES 1 LOW_BYTE_RANGE 0xA1-0xFE END_LOW_BYTE_RANGES STARTSEGMENTS 3 SEGMENT 0xA1A1-0xAFFE "Beijing24.0" 0 SEGMENT 0xB0A1-0xD7F9 "Beijing24.1" 0 SEGMENT 0xD8A1-0xF7FE "Beijing24.2" 0 ENDSEGMENTS ENDFONT ============================================================================== STARTFONT HBF 0.8 COMMENT COMMENT et-kai24fb.hbf (et-k24fb.hbf) COMMENT FONT -ET-Song-Medium-R-Normal-Fan-24-180-100-100-M-240-BIG.FIVE-1 SIZE 24 100 100 FONTBOUNDINGBOX 24 24 0 -3 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "ET" FAMILY_NAME "Kai" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "Fan" PIXEL_SIZE 24 POINT_SIZE 180 RESOLUTION_X 100 RESOLUTION_Y 100 SPACING "M" AVERAGE_WIDTH 240 CHARSET_REGISTRY "BIG.FIVE" CHARSET_ENCODING "1" DEFAULT_CHAR 0xA140 FONT_DESCENT 3 FONT_ASCENT 21 COPYRIGHT "Copyright (c) 1993 ET Corp." ENDPROPERTIES CHARS 13867 START_LOW_BYTE_RANGES 2 LOW_BYTE_RANGE 0x40-0x7E LOW_BYTE_RANGE 0xA1-0xFE END_LOW_BYTE_RANGES STARTSEGMENTS 4 COMMENT Non-hanzi symbols (408 chars) SEGMENT 0xA140-0xA3BF "SPCFONT.24" 0 COMMENT Frequently-used hanzi (5401 chars) SEGMENT 0xA440-0xC67E "STDFONT.24K" 0 COMMENT vendor-specific symbols (365 chars) SEGMENT 0xC6A1-0xC8D3 "SPCFSUPP.24" 0 COMMENT Less-frequently-used hanzi (7693 chars) COMMENT The standard range should be smaller: 0xC940-0xF9D5 (7652 chars) SEGMENT 0xC940-0xF9FE "STDFONT.24K" 388872 ENDSEGMENTS ENDFONT ============================================================================== STARTFONT HBF 0.8 COMMENT COMMENT et-16x24.hbf COMMENT FONT -ET-16x24-Medium-R-Normal--24-180-100-100-M-120-IBM.X.ASCII-1 SIZE 24 100 100 FONTBOUNDINGBOX 16 24 0 -3 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "ET" FAMILY_NAME "16x24" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "" PIXEL_SIZE 24 POINT_SIZE 180 RESOLUTION_X 100 RESOLUTION_Y 100 SPACING "M" AVERAGE_WIDTH 120 COMMENT What is the proper name of IBM PC's extended 8-bit ASCII? CHARSET_REGISTRY "IBM.X.ASCII" CHARSET_ENCODING "1" DEFAULT_CHAR 0x20 FONT_DESCENT 3 FONT_ASCENT 21 COPYRIGHT "Copyright (c) 1993 ET Corp." ENDPROPERTIES CHARS 256 START_LOW_BYTE_RANGES 1 LOW_BYTE_RANGE 0x00-0xFF END_LOW_BYTE_RANGES STARTSEGMENTS 1 COMMENT IBM PC extended ASCII (256 chars) SEGMENT 0x00-0xFF "ASCFONT.24" 0 ENDSEGMENTS ENDFONT ============================================================================== STARTFONT HBF 0.8 COMMENT COMMENT hku-fixed16fb.hbf COMMENT FONT -HKU-Fixed-Medium-R-Normal-Fan-16-120-100-100-M-160-BIG.FIVE-1 SIZE 16 100 100 FONTBOUNDINGBOX 16 16 0 -2 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "HKU" FAMILY_NAME "Fixed" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "Fan" PIXEL_SIZE 16 POINT_SIZE 120 RESOLUTION_X 100 RESOLUTION_Y 100 SPACING "M" AVERAGE_WIDTH 160 CHARSET_REGISTRY "BIG.FIVE" CHARSET_ENCODING "1" DEFAULT_CHAR 0xA140 FONT_DESCENT 2 FONT_ASCENT 14 COPYRIGHT "Copyright (c) 1989 HKU" ENDPROPERTIES CHARS 13524 START_LOW_BYTE_RANGES 2 LOW_BYTE_RANGE 0x40-0x7E LOW_BYTE_RANGE 0xA1-0xFE END_LOW_BYTE_RANGES STARTSEGMENTS 3 COMMENT Non-hanzi symbols (471 chars) with some vendor-specific symbols SEGMENT 0xA140-0xA3FE "chinese.16" 256 COMMENT Frequently-used hanzi (5401 chars) SEGMENT 0xA440-0xC67E "chinese.16" 24736 COMMENT Less-frequently-used hanzi (7652 chars) SEGMENT 0xC940-0xF9D5 "chinese.16" 197568 ENDSEGMENTS ENDFONT ============================================================================== From simpson@math.psu.edu Mon Feb 15 18:20:04 1993 Return-Path: From: Stephen G Simpson Date: Mon, 15 Feb 93 19:10:30 -0500 To: soft-authors@ifcss.org Subject: F. F. Lee's sample HBF 0.8 files Status: O Thank you F. F. Lee for posting five sample HBF 0.8 files. So far as I can tell, the proposed HBF format is very well designed, and I think these samples provide the guidance that programmers need in order to begin incorporating HBF support into their software. In this way we can test the proposed format and uncover any inadequacies that may exist. I don't want to volunteer right now to develop portable and flexible routines to access HBF fonts. The reasons are (1) I am not a very experienced C programmer, (2) my time available to work on this is very limited. However, as time permits, I will start adding HBF support to my FLASH program (described in an earlier posting). And I will try to do it in a modular way, so that others can reuse my code. In the meantime, I have a few questions. First, the proposed HBF format is presumably suitable not only for Chinese bitmap fonts but also for Japanese bitmap fonts. Should we expand our group to include authors of Japanese software? I wonder whether Japanese software authors are working toward or have already arrived at a similar standard. If so, should we try to make our standard compatible with theirs? Just wondering .... Second, I am wondering about the meaning of some of the properties in the sample HBF 0.8 files. I don't understand how the concepts POINT_SIZE, RESOLUTION_X, RESOLUTION_Y 100, SPACING, AVERAGE_WIDTH, CHARSET_ENCODING, FONT_DESCENT, FONT_ASCENT apply to naked bitmaps. I guess this shows my ignorance of the X-Window BDF format. Third, are all the fields in a font name like -CC-Song-Medium-R-Normal-Jian-16-120-100-100-M-160-GB2312.80-1 required? I realize that this is an X window font naming convention, but I am concerned that requiring these long and complicated font names may cause problems. Again, this question is probably due only to my ignorance. Best wishes, Stephen G. Simpson From Ricky.Yeung@Eng.Sun.COM Mon Feb 15 19:55:50 1993 Return-Path: Date: Mon, 15 Feb 93 17:47:11 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) To: simpson@math.psu.edu Cc: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Mon, 15 Feb 93 19:10:30 -0500 <9302160010.AA26673@boole.math.psu.edu> Subject: Re: F. F. Lee's sample HBF 0.8 files Content-Length: 3484 Status: O > From: Stephen G Simpson > Date: Mon, 15 Feb 93 19:10:30 -0500 > Content-Length: 1898 > > Thank you F. F. Lee for posting five sample HBF 0.8 files. So far as > I can tell, the proposed HBF format is very well designed, and I think > these samples provide the guidance that programmers need in order to > begin incorporating HBF support into their software. In this way we > can test the proposed format and uncover any inadequacies that may > exist. One nice thing about HBF is that one can even throw away the existing space-consuming BDF files for Chinese bitmap font if a HBF2BDF utility (which would be simple to write) is provided. Notice that existing font file format such as ET or CCDOS can't preserve the BDF properties. [ ... lines deleted ... ] > First, the proposed HBF format is presumably suitable not only for > Chinese bitmap fonts but also for Japanese bitmap fonts. Should we Yes, it's the intent of HBF to provide a standard for all hanzi(kanji) bitmap font. > expand our group to include authors of Japanese software? I wonder > whether Japanese software authors are working toward or have already > arrived at a similar standard. If so, should we try to make our > standard compatible with theirs? Just wondering .... I think for X11 they just use the standard BDF format. Maybe some one can update us on this front. > Second, I am wondering about the meaning of some of the properties in > the sample HBF 0.8 files. I don't understand how the concepts > POINT_SIZE, RESOLUTION_X, RESOLUTION_Y 100, SPACING, AVERAGE_WIDTH, > CHARSET_ENCODING, FONT_DESCENT, FONT_ASCENT apply to naked bitmaps. I > guess this shows my ignorance of the X-Window BDF format. Those are standard BDF attributes, you can look them up from the X Window documentation. The implementator of a simple limited-purpose HBF library could simply ignore them (see below). I think Fung Fung Lee provided them in the draft just for the sake of completeness. > Third, are all the fields in a font name like > > -CC-Song-Medium-R-Normal-Jian-16-120-100-100-M-160-GB2312.80-1 > > required? I realize that this is an X window font naming convention, > but I am concerned that requiring these long and complicated font > names may cause problems. Again, this question is probably due only > to my ignorance. As put by Fung Fung Lee, the naming convention is not really relevant to the HBF standard and is not required. I think he put it in to try to follow the convention. A base HBF library API may just contain the following routines: /* Open and read in font file. */ HBF_Handle HBF_open_font(char * filename); /* Given a hanzi code, returns a bitmap. */ BITMAP HBF_get_bitmap(HBF_Handle handle, unsigned_int16 code); A simplified example HBF file: ============================================================================== STARTFONT HBF 0.8 FONT hku16 FONTBOUNDINGBOX 16 16 0 -2 STARTPROPERTIES 2 DEFAULT_CHAR 0xA140 COPYRIGHT "Copyright (c) 1989 HKU" ENDPROPERTIES CHARS 13524 START_LOW_BYTE_RANGES 2 LOW_BYTE_RANGE 0x40-0x7E LOW_BYTE_RANGE 0xA1-0xFE END_LOW_BYTE_RANGES STARTSEGMENTS 3 SEGMENT 0xA140-0xA3FE "chinese.16" 256 SEGMENT 0xA440-0xC67E "chinese.16" 24736 SEGMENT 0xC940-0xF9D5 "chinese.16" 197568 ENDSEGMENTS ENDFONT ============================================================================== -Ricky From mcpong@uxmail.ust.hk Mon Feb 15 20:01:29 1993 Return-Path: Date: Tue, 16 Feb 93 09:55:16 HKT From: mcpong@uxmail.ust.hk (Dr. PONG Man Chi) To: soft-authors@ifcss.org Subject: HBF definition document Cc: mcpong@uxmail.ust.hk Status: O > From simpson@math.psu.edu Tue Feb 16 08:13:27 1993 > Subject: F. F. Lee's sample HBF 0.8 files > > Second, I am wondering about the meaning of some of the properties in > the sample HBF 0.8 files. I don't understand how the concepts > POINT_SIZE, RESOLUTION_X, RESOLUTION_Y 100, SPACING, AVERAGE_WIDTH, > CHARSET_ENCODING, FONT_DESCENT, FONT_ASCENT apply to naked bitmaps. I > guess this shows my ignorance of the X-Window BDF format. > > Third, are all the fields in a font name like > > -CC-Song-Medium-R-Normal-Jian-16-120-100-100-M-160-GB2312.80-1 > > required? I realize that this is an X window font naming convention, > but I am concerned that requiring these long and complicated font > names may cause problems. Having read the latest mail, many seem to agree that it's time to really write something down; and there's some urgency. Thank F.F.Lee for his idea of ranges of codes. I am writing a definition document of HBF, and nice to see F.F.Lee's sample HBF files appearing. I'll try to mail out a draft document in two day's time. Many of the above queries are related to the X font attributes. I am thinking of how to mention these in the draft document. Please comment on the draft document when it appears. Back to work now :-) mcpong From CAI@neurophys.wisc.edu Mon Feb 15 21:52:45 1993 Return-Path: Date: Mon, 15 Feb 93 21:35 CST From: CAI@neurophys.wisc.edu Subject: Re: HBF definition document To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O .From: IN%"mcpong@uxmail.ust.hk" 15-FEB-1993 19:52:49.79 .To: soft-authors@ifcss.ORG .I am writing a definition document of HBF, and nice to see .F.F.Lee's sample HBF files appearing. I'll try to mail out .a draft document in two day's time. Thank you very much and I really appreciate your effort. I am not familar with the DBF conventions and may be some other people have similar problems. So could you explain those definitions a little bit when you write the draft document? Yidao