From simpson@math.psu.edu Fri Oct 1 09:09:17 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA11533; Fri, 1 Oct 93 09:09:17 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id KAA06584; Fri, 1 Oct 1993 10:14:10 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 1 Oct 1993 10:14:08 -0400 Date: Fri, 1 Oct 1993 10:14:08 -0400 Message-Id: <199310011414.KAA21576@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: .hbf inconsistencies? Status: RO Nelson Chin writes: > i got the cclib16.hbf and cclibf24.hbf from ifcss.org and compared them and > found some differences, ie: > > % testhbf cclib16 8abd > shows n' > % testhbf cclib24f 8abd > shows m' > > which one is correct? > > Nelson 8abd is not a valid character code for the cclib fonts. I think Nelson meant a8bd. I'm not sure what testhbf is but maybe it is the same as tester.c in Ross's HBF API implementation. "tester cclib16 a8bd" shows m' for me. I don't know about cclib24f or cclibf24, I can't find these HBF files at ifcss.org. Maybe Nelson could clarify? But I agree with Nelson's general point: it is important to make these .hbf files as accurate and correct as possible. -- S. Simpson From jiang Fri Oct 1 09:33:56 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA12475; Fri, 1 Oct 93 09:33:56 CDT Date: Fri, 1 Oct 93 09:33:56 CDT From: jiang (Yuan Jiang) Message-Id: <9310011433.AA12475@ifcss.org> To: soft-authors Subject: Re: Directory information in HBF file or environmental variable Status: RO I don't believe HBF has no use to PC developers. Only those who "have" fonts, their hard-worded on fonts, don't want to throw away their outdated work easily. But HBF will benefit most of the new programmers. Font development should be left to font foundries, such as Adobe. It's a shame that programmers have been having to spend so much time on fonts. From butta1@cs.bu.edu Fri Oct 1 10:39:36 1993 Return-Path: Received: from cs-mail.bu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA14792; Fri, 1 Oct 93 10:39:36 CDT Received: from CSA.BU.EDU by cs-mail.bu.edu (5.61+++/Spike-2.1) id AA08023; Fri, 1 Oct 93 11:38:08 -0400 From: butta1@cs.bu.edu (Nelson Chin) Received: by csa.bu.edu (5.61+++/Spike-2.1) id AA20137; Fri, 1 Oct 93 11:38:06 -0400 Date: Fri, 1 Oct 93 11:38:06 -0400 Message-Id: <9310011538.AA20137@csa.bu.edu> To: soft-authors@ifcss.org Subject: [simpson@math.psu.edu: .hbf inconsistencies?] Reply-To: butta1@cs.bu.edu (nelson chin) Status: RO < < From: Stephen G Simpson < Date: Fri, 1 Oct 1993 10:14:08 -0400 < < Nelson Chin writes: < > i got the cclib16.hbf & cclibf24.hbf from ifcss.org and compared them & < > found some differences, ie: < > < > % testhbf cclib16 8abd < > shows n' < > % testhbf cclib24f 8abd < > shows m' < > < > which one is correct? < > < > Nelson < < 8abd is not a valid character code for the cclib fonts. I think < Nelson meant a8bd. I'm not sure what testhbf is but maybe it is the < same as tester.c in Ross's HBF API implementation. "tester cclib16 < a8bd" shows m' for me. I don't know about cclib24f or cclibf24, I < can't find these HBF files at ifcss.org. Maybe Nelson could clarify? < < But I agree with Nelson's general point: it is important to make these < .hbf files as accurate and correct as possible. < < -- S. Simpson < see ifcss.org: /software/fonts/HBF/cclib16.hbf /software/fonts/gb6345.zip <-- cclibf24.hbf is in here /software/fonts/gb6345.txt says: RPC National Standard GB6345.1 32X32 Dot matrix font set and data set of Chinese ideograms for information interchange Published on 1986-05-03 Executes on 1986-12-01 GB 6345.1-86 3 Chinese ideograms Based on GB 2312-80: Qu 1-9 682 oreign charachers and other ideograms Qu 15-55 3755 first level Chinese ideograms Qu 56-87 3008 second level Chinese ideograms Addition of 6 ideograms between 8-27(QuWei) and 8-32 (a m' n' nv n` g). Addition of 94 half-ideograms in Qu 10, the sequence of the ideograms is identical to Qu 3 of the GB2312 Table 1 . The width of each ideogram is one half of that found in Qu 3. Appendix A - Explaination of Ideograms addition and correction (Supplement) This standard is based on GB2312. Based on usage requirement. The following additions and corrections on ideograms should be used until GB2312 is being revised. After GB2312 is being revised, use GB2312 as stanard. There are 102 additions and corrections, refer to following table: a. 3-7 g corrected to g b. 8-27 to 8-32 add (a m' n' nv n` g) *NOTE 1 c. 10-01 to 10-94 addtion of 94 half-ideograms d. 79-81 correction of the ideogram dot-matrix *NOTE 2 Popose to use 11-01 to 11-32 of GB2312 table 1 as new half-ideograms Qu. The sequence of the ideograms is identical to 8-01 to 8-32 of this standard. The width of each ideogram is one half of that found in Qu 8. *NOTE 1 # # # # # # # # # # # # ## # ### ### #### ## ##### # # # # # # #### #### #### # #### # ## ## ## # # ## # # ## # # ## # # # # # # # # ## # ## # ## # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #### # # # # # # # # # # # # # # # # # # # # # # # # # ## # # # # # # # # # ### ##### # # # # # # # # # # ###### ## # # # # # ## # ###### *NOTE 2 ### ### ### ### ## ## ## ## ## ## ## ## ## ## ## ## # ## ############## # ## ############## ## # # ## ## # # ## # # ## # # ## # ## ## # # ## ## # ######## ############### ######## ############### # ## # ## ## ## ## # ############# ## # ############# ######### ## ## ### to ######### ## ## ### ## ## ## ## ## ## ## ## ## ############ ## ############ # ## # ## ## ## ## ## ## ## # ## # ############ ## ############ # ## # ## ## ## # ### ## ## ## ## ############# ## ############# ##### ## ##### ## ##### ## ##### ## ### ################# ### ################# From khsc@synoptics.com Fri Oct 1 11:47:14 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA19916; Fri, 1 Oct 93 11:47:14 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA19173; Fri, 1 Oct 93 09:44:22 PDT Received: by taichi (4.1/2.0N) id AA03941; Fri, 1 Oct 93 09:44:21 PDT Message-Id: <9310011644.AA03941@taichi> Date: Fri, 1 Oct 93 09:44:21 PDT From: Simon Chow To: butta1@cs.bu.edu, soft-authors@ifcss.org Subject: gb6345 Status: RO > From butta1@cs.bu.edu Thu Sep 30 21:10:40 1993 > > i got the cclib16.hbf and cclibf24.hbf from ifcss.org and compared them and > found some differences, ie: > > % testhbf cclib16 8abd > shows n' > % testhbf cclib24f 8abd > shows m' > > which one is correct? > > Nelson aabd (you do mean aabd, right) should be n', are you using the cclibf24.hbf in ifcss.org:/software/fonts/gb6345.zip? I use the "tester" program to verify that aabd represents n' just now. |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. From butta1@cs.bu.edu Fri Oct 1 17:01:34 1993 Return-Path: Received: from cs-mail.bu.edu by ifcss.org (4.1/IFCSS-Mailer) id AB05803; Fri, 1 Oct 93 17:01:34 CDT Received: from CSA.BU.EDU by cs-mail.bu.edu (5.61+++/Spike-2.1) id AA15324; Fri, 1 Oct 93 17:59:57 -0400 From: butta1@cs.bu.edu (Nelson Chin) Received: by csa.bu.edu (5.61+++/Spike-2.1) id AA19956; Fri, 1 Oct 93 17:59:51 -0400 Date: Fri, 1 Oct 93 17:59:51 -0400 Message-Id: <9310012159.AA19956@csa.bu.edu> To: khsc@synoptics.com Cc: soft-authors@ifcss.org In-Reply-To: <9310011644.AA03941@taichi> (message from Simon Chow on Fri, 1 Oct 93 09:44:21 PDT) Subject: Re: gb6345 Reply-To: butta1@cs.bu.edu (nelson chin) Status: RO > Date: Fri, 1 Oct 93 09:44:21 PDT > From: Simon Chow > > > From butta1@cs.bu.edu Thu Sep 30 21:10:40 1993 > > > > i got the cclib16.hbf and cclibf24.hbf from ifcss.org and compared them and > > found some differences, ie: > > > > % testhbf cclib16 8abd > > shows n' > > % testhbf cclib24f 8abd > > shows m' > > > > which one is correct? > > > > Nelson > > aabd (you do mean aabd, right) should be n', are you using the cclibf24.hbf in > ifcss.org:/software/fonts/gb6345.zip? I use the "tester" program to verify that > aabd represents n' just now. oops i mean cclib16 shows m' and cclibf24 shows n'. and is the gb6345 available for the other gb fonts? i guess then /software/fonts/cclib16.a needs to be fixed then. nelson From mcpong@cs.ust.hk Fri Oct 1 22:01:07 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA12330; Fri, 1 Oct 93 22:01:07 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA24327; Sat, 2 Oct 93 10:59:13 HKT Date: Sat, 2 Oct 93 10:59:13 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310020259.AA24327@cs.ust.hk> In-Reply-To: butta1@cs.bu.edu (Nelson Chin) "Re: gb6345" (Oct 2, 6:05) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: butta1@cs.bu.edu (nelson chin) Subject: Re: gb6345 Cc: soft-authors@ifcss.org Status: RO -- "butta1@cs.bu.edu (Nelson Chin)" wrote on 1993 Oct 1 (Fri): > see ifcss.org: > > /software/fonts/HBF/cclib16.hbf > /software/fonts/gb6345.zip <-- cclibf24.hbf is in here > > /software/fonts/gb6345.txt says: > [[ ... deleted ]] cclib16.hbf, based on GB2312-80, says: HBF_CODE_RANGE 0xA1A1-0xA7FE cclib.16 0 HBF_CODE_RANGE 0xA8A1-0xA9FE cclib.16a 0 HBF_CODE_RANGE 0xB0A1-0xF7FE cclib.16 21056 There's no code in 0xaabd (or 0x8abd, if not high-bit-on in first byte). tester cclib16.hbf aabd HBF_START_FONT 1.0 HBF_CODE_SCHEME GB2312-1980 FONT cclib16 HBF_BITMAP_BOUNDING_BOX 16 16 0 -2 FONTBOUNDINGBOX 16 16 0 -2 FAMILY_NAME "Song" CHARS 7614 tester: unknown char aabd (aabd) If it shows something in Nelson's version of cclib16.hbf at 0xaabd (or 0x8abd), then it must be an extra glyph occupied some unused coding space of GB2312-80. --------- GB6345.1 is based on an **extension** of GB2312-80. Thus, it is not surprised that there're more glyphs in GB6345.1. I have a copy of GB6345.1, as an appendix in a Chinese book published in 1989, which says the same thing as Nelson has quoted. As far as I know, there is only one version of GB2312-80. The proposed extension of GB2312-80 mentioned in GB6345.1 has not been formally adopted -- however, I must state that my knowledge of the "latest" GB standard is not up to date. m c From simpson@math.psu.edu Sat Oct 2 12:50:19 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA25845; Sat, 2 Oct 93 12:50:19 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id NAA16795; Sat, 2 Oct 1993 13:48:56 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Sat, 2 Oct 1993 13:48:55 -0400 Date: Sat, 2 Oct 1993 13:48:55 -0400 Message-Id: <199310021748.NAA22957@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: GB6345 Status: RO OK, I finally figured out the point that Nelson was trying to make. The point is that there is a document called GB6345 which purports to explain some recent changes in the GB standard. (This document is available in ifcss.org:/software/fonts/gb6345.zip.) According to this document, the code range A8BB to A8C0 (6 codes, Qu-Wei 8-27 to 8-32) should represent letters that look something like a, m', n', mv, n`, g, but in /software/fonts/HBF/cclib16.hbf this is scrambled to a, g, m', n', nv, n`, and in at least some of the other cclib*.hbf fonts in /software/fonts/HBF, this range is filled with blanks. So, I guess whoever created these HBF/cclib*.hbf fonts should fix them up to conform with GB6345. Obviously this is not crucial for HBF applications, but it would be nice for these publically available HBF fonts to be as correct as possible. -- Steve From CAI@neurophys.wisc.edu Sat Oct 2 14:08:24 1993 Return-Path: Received: from neurophys.wisc.edu (mve.neurophys.wisc.edu) by ifcss.org (4.1/IFCSS-Mailer) id AA27152; Sat, 2 Oct 93 14:08:24 CDT Received: from VMSmail by neurophys.wisc.edu; Sat, 2 Oct 93 14:04 CST Message-Id: <23100214045824@neurophys.wisc.edu> Date: Sat, 2 Oct 93 14:04 CST From: CAI@neurophys.wisc.edu Subject: Comments on Chen's Posting To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO ------ I saw Mr./Ms. Chen's posting. There are some interesting points out there, some I agree and some I don't quite agree. I am not in the field of CS or any related fields and I do not even consider myself a programmer. I do it just for fun. >From: IN%"gchen@geohub.gcn.uoknor.EDU" 30-SEP-1993 14:26:53.51 Subj: Re: Directory information in HBF file or environmental variable 2. Do we really need HBF? I don't see many PC programmers' positive response. ------ I think yes. And it indeed helps. A PC user/programmer approached me for how to get the bitmap information of a font, I refered him to HBF and Ross' API, and he was happy to tell me later that he could display Chinese characters on his screen. If HBF is not good enough, it will die itself, no matter how hard one promotes it. It is the freedom of programmers whether to use it or not. It is also the freedom of other people who want to promote it. for intellectual properties. The font and file formats are known by most programmers. Are we going to see more 24x24 or even some 48x48 ------ But not by those non-programmers like me who just want to have some fun. (or I could be the most stupid non-programmer) It took me a month to figure out the organization in a font two years ago. I had some fun though. But I think I might have had more fun if I could just figure it out in a week. fonts that can be accessible to the public? I doubt. Today, most commercial Chinese softwares will either compress the fonts (24x24 or whatever, including the scalable fonts) or encrypt them. Will our programs be able to access them by using a .HBF file? On the BIG5 side, I don't know much about it. ------ Yes, we could not expect more free fonts availabe in public, either bitmap fonts or true type fonts. For most non-programmers who just want to have some fun, and some programmers, the only chioce is to play with bitmap fonts in the near future. 1. C is not the only languages that are popular for PC. Pascal, Basic, even Fortran have been observed in writing Chinese programs. Who is gonna write the API's for these languages? Many "new" programmers, hobbists simply can't write them own API, particularly in languages like BASIC, and FORTRAN. If HBF is made only for users, but not also for peoples who want to learn to how to write Chinese programs, HBF should be at least partly a failure. ------- I agree with this point. Why not some experienced programmers do our non-programmers a favour? BTW, on VMS, it should be possible to make use of APIs written in other languages (some modification of the original API may be needed, or we can build somethinf on top of it). I am not sure if this is also true in other systems. for the Chinese files on the net? My point is what kind of coding scheme or font that a program will use is purely the freedom of the programmer. ------ agree. But if one can support more than one coding scheme almost for free, some people may be willing to have a try. (My assumption is that some people may not know this free lunch. I could be wrong.) Whether the programs will be used by many people will be determined by the users not by the few programmers. ------ same is true for HBF. Yidao Cai From YUAN@NIEHS.NIH.GOV Sun Oct 3 07:27:09 1993 Return-Path: Received: from NIEHS.NIH.GOV (vaxe.niehs.nih.gov) by ifcss.org (4.1/IFCSS-Mailer) id AA09383; Sun, 3 Oct 93 07:27:09 CDT Received: from NIEHS.NIH.GOV by NIEHS.NIH.GOV (PMDF V4.2-13 #3461) id <01H3O3S4WX7890NNFE@NIEHS.NIH.GOV>; Sun, 3 Oct 1993 08:26:19 EDT Date: Sun, 03 Oct 1993 08:26:19 -0400 (EDT) From: Jin-hua Yuan Subject: unsub To: soft-authors@ifcss.org Message-Id: <01H3O3S4WX7A90NNFE@NIEHS.NIH.GOV> X-Vms-To: IN%"soft-authors@ifcss.org" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: RO Please remove my name from distribution list because my vax account will not be available to me in the near future. Thanks. Jinhua yuan Yuan@niehs.nih.gov From simpson@math.psu.edu Sun Oct 3 19:09:38 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA23359; Sun, 3 Oct 93 19:09:38 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id UAA20967; Sun, 3 Oct 1993 20:08:13 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Sun, 3 Oct 1993 20:08:11 -0400 Date: Sun, 3 Oct 1993 20:08:11 -0400 Message-Id: <199310040008.UAA24308@boole.math.psu.edu> To: CAI@neurophys.wisc.edu Cc: soft-authors@ifcss.org In-Reply-To: <23100213434113@neurophys.wisc.edu> Subject: Re: GB6345 Status: RO Probably I was too hasty in asking for a revision of the HBF/cclib*.hbf fonts to conform with GB6345. Actually, I'm not quite sure what to think about GB6345. From the GB6345 document: > Published on 1986-05-03 > Executes on 1986-12-01 > > GB 6345.1-86 > This stnadard is based on GB2312. Based on usage requirement. The following > additions and corrections on ideograms should be used until GB2312 is being > revised. After GB2312 is being revised, use GB2312 as stanard. I can't be sure whether this is an official update to GB2312, or merely a proposed addition. Maybe we should just ignore it? This points up the fact that it may not be completely easy to obtain accurate information about standards such as GB2312 or Big5. -- Steve From mcpong@cs.ust.hk Sun Oct 3 20:17:32 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA24126; Sun, 3 Oct 93 20:17:32 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA28570; Mon, 4 Oct 93 09:16:04 HKT Date: Mon, 4 Oct 93 09:16:04 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310040116.AA28570@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: ignore GB6345 w.r.t. hbf Status: RO -- "Stephen G Simpson " wrote on 1993 Oct 4 (Mon): > Probably I was too hasty in asking for a revision of the > HBF/cclib*.hbf fonts to conform with GB6345. Actually, I'm not quite > sure what to think about GB6345. From the GB6345 document: > > > Published on 1986-05-03 > > Executes on 1986-12-01 > > > > GB 6345.1-86 > > > This stnadard is based on GB2312. Based on usage requirement. The following > > additions and corrections on ideograms should be used until GB2312 is being > > revised. After GB2312 is being revised, use GB2312 as stanard. > > I can't be sure whether this is an official update to GB2312, or > merely a proposed addition. Maybe we should just ignore it? This > points up the fact that it may not be completely easy to obtain > accurate information about standards such as GB2312 or Big5. > > -- Steve IMHO, I suggest we can ignore GB6345 with respect to HBF files. GB2312-80 is the official standard. GB6345.1-86 is a 32x32 bitmap standard set. (The PRC Government has some standards on the appearances of characters of several bitmap sizes.) One may write an HBF file to specify a font (i.e., its bitmap files) based on a particular variant of GB2312-80 encoded characters. That's all. HBF/cclib*.hbf are for fonts conformed to GB2312-80 which is published in 1980. GB2312-80 is well defined and the official publication can be obtained from the Standard Bureau (publishing house) in Beijing (if the stock still lasts). mcpong From xiaofei Mon Oct 4 11:10:35 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA03597; Mon, 4 Oct 93 11:10:35 CDT Date: Mon, 4 Oct 93 11:10:35 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9310041610.AA03597@ifcss.org> To: soft-authors Subject: reaction from software authors Status: RO After I mailed the message `soft-authors_discussion_list_and_HBF_file' to authors who have submitted softwares to ifcss.org, I received the following reponses in one day. Christian Wittern from Kyoto has some suggestions to HBF authors, see below. -- >From rwong@gucis.cit.gu.edu.au Mon Oct 4 00:14:01 1993 Return-Path: Received: from gucis.cit.gu.edu.au by ifcss.org (4.1/IFCSS-Mailer) id AA27806; Mon, 4 Oct 93 00:13:58 CDT Received: by gucis.cit.gu.edu.au id AA20832 (5.65c/IDA-1.4.4 for xiaofei@ifcss.org); Mon, 4 Oct 1993 15:07:56 +1000 Date: Mon, 4 Oct 1993 15:07:56 +1000 >From: Richard Wong Message-Id: <199310040507.AA20832@gucis.cit.gu.edu.au> Apparently-To: xiaofei@ifcss.org Status: RO -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To: xiaofei@ifcss.org Subject: Re: soft-authors_discussion_list_and_HBF_file In-Reply-To: Mail from 'xiaofei@ifcss.org (XiaoFei Wang)' dated: Sun, 3 Oct 93 21:46:46 CDT Hello I got your mail about the soft-authors and the hbf fonts. I feel this is a great idea! The non-standard chinese font make the programmer a lot of problem. I will spend some time look at it and I will try using the hbf font later (if possiable). Also, Please let me in your soft-authors mailing list (PS : my UNIX account is on until the end of 93 (Study Finish) I may or may not get a new account for next year.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------------------------- | 0000000000000000 | | 00000000000000000000000000 | | 00000000000000000000000000000000 | | 000000000000000000000000000000000000 | | 00000000000 0000000000000000 00000000000 | | 00000000000 00000000000000 00000000000 | | 0000000000000 0000000000000000 0000000000000 | | 0000000000000000000000000000000000000000000000 | | 0000000 0000000000000000000000000000000 000000 | | 00000 0000000000000000000000000000000000 00000 | | 000 000 000000000000000000000000000000 000 000 | | 00000000 00000000000000000000000000 00000000 | | 0000000000 000000000000000000000 000000000 | | 00000000000 00000000000000 00000000000 | | 00000000000 00000000000 | | 00000000000000000000000000000000 | | 00000000000000000000000000 | | 0000000000000000 | |_________________________________________________________________________| ------------------------------------------------------------------------- | From : Richard Wong (Sai Ho) ~{;FJ@:@~} | | : Bachelor of Informatics | | : Australia (QLD) Griffith University | | Email address : - < rwong@gucis.cit.gu.edu.au > | ------------------------------------------------------------------------- >From @YaleVM.YCC.Yale.Edu:WLIU%DAC@YALPH2.BITNET Mon Oct 4 02:13:34 1993 Return-Path: <@YaleVM.YCC.Yale.Edu:WLIU%DAC@YALPH2.BITNET> Received: from YaleVM.YCC.Yale.Edu by ifcss.org (4.1/IFCSS-Mailer) id AA28565; Mon, 4 Oct 93 02:13:28 CDT Received: from YALPH2.BITNET by YaleVM.YCC.Yale.Edu (IBM VM SMTP V2R2) with BSMTP id 6094; Mon, 04 Oct 93 03:10:20 EDT Received: from YALPH2 (WLIU@DAC) by YALPH2 (PMDF #2531 ) id <01H3P76QPLM88Y5K1Q@YALPH2>; Mon, 4 Oct 1993 03:13:02 EST Date: 04 Oct 1993 03:13:02 -0500 (EST) >From: WLIU%DAC%YALPH2.bitnet@YaleVM.YCC.Yale.Edu Subject: Re: soft-authors_discussion_list_and_HBF_file To: xiaofei@ifcss.org Message-Id: <01H3P76QPV9E8Y5K1Q@YALPH2> X-Envelope-To: xiaofei@ifcss.org X-Vms-To: YALPHY::IN%"xiaofei@ifcss.org" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: RO I'd like to join the list. Thanks! >From wchwang@csie.nctu.edu.tw Mon Oct 4 03:47:41 1993 Return-Path: Received: from csie.nctu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA29069; Mon, 4 Oct 93 03:47:38 CDT Received: from ccsun1.csie.nctu.edu.tw by csie.nctu.edu.tw (4.1/SMI-4.1(phoenix New)) id AA03821; Mon, 4 Oct 93 16:49:13 CST >From: wchwang@csie.nctu.edu.tw (Wei-Chung Hwang) Message-Id: <9310040849.AA03821@csie.nctu.edu.tw> Subject: Re: soft-authors_discussion_list_and_HBF_file To: xiaofei@ifcss.org (XiaoFei Wang) Date: Mon, 4 Oct 1993 16:49:59 +0800 (CST) In-Reply-To: <9310040246.AA25787@ifcss.org> from "XiaoFei Wang" at Oct 3, 93 09:46:20 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 242 Status: RO Please add me to the list, thanks. -- Wei-Chung Hwang ------------------ Email: wchwang@csie.nctu.edu.tw, wchwang@gsm1.csie.nctu.edu.tw Phone: 886-35-712121 ext: 3787(lab.) 886-4-8751065(home) ------------------------------- >From g53150@sakura.kudpc.kyoto-u.ac.jp Mon Oct 4 04:04:25 1993 Received: from kudpc.kudpc.kyoto-u.ac.jp by ifcss.org (4.1/IFCSS-Mailer) id AA29152; Mon, 4 Oct 93 04:04:13 CDT Received: from sakura.kudpc.kyoto-u.ac.jp by kudpc.kudpc.kyoto-u.ac.jp (5.67+1.6W/2.7W) id AA17633; Mon, 4 Oct 93 18:02:40 JST Received: by sakura.kudpc.kyoto-u.ac.jp (4.1/6.4J.6) id AA07140; Mon, 4 Oct 93 18:02:50 JST Date: Mon, 4 Oct 93 18:02:50 JST >From: "christian wittern" Return-Path: Message-Id: <9310040902.AA07140@sakura.kudpc.kyoto-u.ac.jp> To: xiaofei@ifcss.org Subject: Re: soft-authors_discussion_list_and_HBF_file Status: RO > > Hello -- > Hello! > And I would like to invite you to join soft-authors discussion list and > to ask you to consider using Hanzi Bitmap Fonts description file ( HBF > file for short) in your future release/update of software(s) involving > the Hanzi Bitmap Fonts display. Thank You, I would like to join the list. I'm glad you brought this list to my attention, since I have been wishing to bring the following to the atuthors of HBF: HBF is a very welcome initiative to reduce the unnecessary load on harddisks of many a computer user. Now I would like the creators of this standard to consider an extension in three ways: 1. Inclusion of Unicode. Unicode as a subset of ISO 604*** is certainly the code standard of the future. It is certainly desirable to have shareware and PD software supporting Unicode as soon as possible. For the CJK area, I think this could be done with a minimal Latin support and th Unicode Han-Character range, with covers ca. 21000 Characters from BIG5, GB, JIS, KSC ... (details can be found at unicode.com:pub/mapping-tables/cjkrefx.doc). I'm planning to release a UniHan font for PD use in 32*32 and 64*64, (possibly also 24*24) covering all CJK Characters maybe within the next 6 weeks. This material will be mostly taken from the CCDB database at NCTUCCCA. 2. Considering a scheme for font-compression. With 16*16 GB-fonts, this hardly matters, but a 64*64 UniHan font would uncompressed be about 10 MB - hardly something for everybody's harddisk. 3. Support for CCCII. I know, this might be difficult, so I just ask your opinion. I would love to see usable and free CCCII applications as soon as possible. Greetings, Christian Wittern, Kyoto >From xiaokun@stats.gla.ac.uk Mon Oct 4 04:09:39 1993 Return-Path: Received: from hillhead.cent.gla.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA29168; Mon, 4 Oct 93 04:09:37 CDT Received: from milkyway.stats.gla.ac.uk by jess.glasgow.ac.uk with SMTP (PP) id <16814-0@jess.glasgow.ac.uk>; Mon, 4 Oct 1993 10:08:11 +0100 >From: Xiaokun Zhu Date: Mon, 4 Oct 93 10:10:43 BST Message-Id: <20507.9310040910@milkyway.stats.stats.gla.ac.uk> To: xiaofei@ifcss.org Subject: Re: soft-authors_discussion_list_and_HBF_file Status: RO Hi, xiaofei Thank you for the message of HBF, I know HBF but I'm not in soft-authors, I like join this mail list. cheers! ---xiaokun >From ucc02au@sunmail.lrz-muenchen.de Mon Oct 4 04:18:48 1993 Return-Path: Received: from cd1.lrz-muenchen.de by ifcss.org (4.1/IFCSS-Mailer) id AA29221; Mon, 4 Oct 93 04:18:40 CDT Received: from sunserver.lrz-muenchen.de by cd1.lrz-muenchen.de id SMTP-0012cafea11027033; Mon, 4 Oct 93 10:17:05 +0100 Received: from sun3.lrz-muenchen.de by sunserver.lrz-muenchen.de (4.1/SMI-4.1) id AA04618; Mon, 4 Oct 93 10:17:04 +0100 Received: by sun3.lrz-muenchen.de (4.1/SMI-4.1) id AA00632; Mon, 4 Oct 93 10:17:04 +0100 >From: ucc02au@sunmail.lrz-muenchen.de (HU Bo) Message-Id: <9310040917.AA00632@sun3.lrz-muenchen.de> Subject: Re: soft-authors_discussion_list_and_HBF_file To: xiaofei@ifcss.org (XiaoFei Wang) Date: Mon, 4 Oct 1993 10:17:04 +0100 (MET) In-Reply-To: <9310040246.AA25774@ifcss.org> from "XiaoFei Wang" at Oct 3, 93 09:46:19 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 158 Status: RO Dear XiaoFei, I am very interested in your soft-author list. Please add my e-mail address to this list. Thanks. Hu Bo ucc02au@sunmail.lrz-muenchen.de >From @vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it Mon Oct 4 07:30:01 1993 Return-Path: <@vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it> Received: from vm.cnuce.cnr.it by ifcss.org (4.1/IFCSS-Mailer) id AA00418; Mon, 4 Oct 93 07:29:58 CDT Received: from ICIL64.CILEA.IT by vm.cnuce.cnr.it (IBM VM SMTP V2R2) with BSMTP id 0346; Mon, 04 Oct 93 13:28:16 MET Received: from ICIL64.CILEA.IT by ICIL64.CILEA.IT (PMDF V4.2-11 #2920) id <01H3PSMCYNWW9S41M8@ICIL64.CILEA.IT>; Mon, 4 Oct 1993 13:27:19 MET-DST Date: Mon, 4 Oct 1993 13:27:18 MET-DST >From: CBOGANG@icil64.cilea.it Subject: Re: soft-authors_discussion_list_and_HBF_file To: xiaofei@ifcss.org Message-Id: <01H3PSMD004Y9S41M8@ICIL64.CILEA.IT> X-Envelope-To: xiaofei@ifcss.org X-Vms-To: IN%"xiaofei@ifcss.org" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: RO Thank you for your email. I'd like to join the soft-authors mailing list. Regards, Tian From simpson@math.psu.edu Mon Oct 4 11:37:25 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA04259; Mon, 4 Oct 93 11:37:25 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id MAA24376; Mon, 4 Oct 1993 12:36:01 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Mon, 4 Oct 1993 12:35:59 -0400 Date: Mon, 4 Oct 1993 12:35:59 -0400 Message-Id: <199310041635.MAA25087@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: Unicode Status: RO I would like to second Christian Wittern's suggestion to support Unicode when possible. Right now the problem is that we don't have any Unicode fonts, but Christian mentioned that he is putting one together and will release it soon. Also, so far as I can tell, a Unicode font is mostly just a combination of various alphabets and symbol libraries plus fonts for Chinese and Korean Hangul. So once all the libraries have been assembled, it should be straightforward to handle this by HBF! But maybe I am underestimating the difficulty. -- Steve From khsc@synoptics.com Mon Oct 4 12:37:11 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA05398; Mon, 4 Oct 93 12:37:11 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA26369; Mon, 4 Oct 93 10:34:16 PDT Received: by taichi (4.1/2.0N) id AA05458; Mon, 4 Oct 93 10:34:16 PDT Message-Id: <9310041734.AA05458@taichi> Date: Mon, 4 Oct 93 10:34:16 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: gb6345 Status: RO > From mcpong@cs.ust.hk Fri Oct 1 20:06:29 1993 > > As far as I know, there is only one version of GB2312-80. > The proposed extension of GB2312-80 mentioned in GB6345.1 > has not been formally adopted -- however, I must state that my > knowledge of the "latest" GB standard is not up to date. > GB6345.1 and GB6345.2 were being adopted adopted as of 1986-12-1 as specified in the document. (see gb6345.txt). I have the original document and gb6345.gb is direct quoted. gb6345.txt is a translation of gb6345.gb. The only portion that was not clearly adpopted is the last paragraph: "Propose to use 11-01 to 11-32 of GB2312 table 1 as new half-ideograms Qu. The sequence of the ideograms is identical to 8-01 to 8-32 of this standard. The width of each ideogram is one half of that found in Qu 8." |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. From khsc@synoptics.com Mon Oct 4 12:38:53 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA05416; Mon, 4 Oct 93 12:38:53 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA26375; Mon, 4 Oct 93 10:35:57 PDT Received: by taichi (4.1/2.0N) id AA05482; Mon, 4 Oct 93 10:35:57 PDT Message-Id: <9310041735.AA05482@taichi> Date: Mon, 4 Oct 93 10:35:57 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: GB6345 Status: RO > From simpson@math.psu.edu Sat Oct 2 10:56:15 1993 > > So, I guess whoever created these HBF/cclib*.hbf fonts should fix them > up to conform with GB6345. Obviously this is not crucial for HBF > applications, but it would be nice for these publically available HBF > fonts to be as correct as possible. > My original reason for creating gb6345.24 (bitmap file for gb6345) was to to allow me to write a HP laser printer printing program which allows mix GB and ascii code. I am sure that anyone who has attempt the effort has encounter the same problem. GB is two byte long and ASCII is one byte long, it is only natural that a Chinese ideogram occupy twice the width of an ASCII character. now the problem is that GB bitmap is defined in an externl file such as cclib.*24, and ASCII font is not. I need an ASCII bitmap file that is half the width of the GB bitmap file. I encounter this problem 6 years ago when I first wrote my laser printer program. I kind of side step the problem by translating all ASCII into GB QU 3 characters. Recently. I was cleaning up my den and found the GB6345 document, read it in full for the frist time. Found exactly what I need, "half-Zi ideograms" is part of the GB6345 standard which revised GB2312-80. I created gb6345.24 to be used together with cclib.*24 bitmap files. I have not done modifying my printing program yet. However, I think there are people such as yourself who whould be interested in the gb6345 info, so I uploaded the essential portion of the gb6345 document the bitmap file and the HBF file so that eveyone can benifit. If I can squeece out more time, I will create a gb6345.16 file and the associate HBF file for the 16 bit fonts. But anyone who is interested is welcome to do this before I got to it. |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. From khsc@synoptics.com Mon Oct 4 12:39:14 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA05454; Mon, 4 Oct 93 12:39:14 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA26381; Mon, 4 Oct 93 10:36:20 PDT Received: by taichi (4.1/2.0N) id AA05486; Mon, 4 Oct 93 10:36:19 PDT Message-Id: <9310041736.AA05486@taichi> Date: Mon, 4 Oct 93 10:36:19 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: ignore GB6345 w.r.t. hbf Status: RO > From mcpong@cs.ust.hk Sun Oct 3 18:26:28 1993 > > > > > Published on 1986-05-03 > > > Executes on 1986-12-01 > > > > > > GB 6345.1-86 > > > > > This stnadard is based on GB2312. Based on usage requirement. The following > > > additions and corrections on ideograms should be used until GB2312 is being > > > revised. After GB2312 is being revised, use GB2312 as stanard. > > > > I can't be sure whether this is an official update to GB2312, or > > merely a proposed addition. Maybe we should just ignore it? This > > points up the fact that it may not be completely easy to obtain > > accurate information about standards such as GB2312 or Big5. > > > > -- Steve > > IMHO, I suggest we can ignore GB6345 with respect to HBF files. > > GB2312-80 is the official standard. GB6345.1-86 is a 32x32 bitmap * so is GB6345.1-86 and GB6345.2-86! > standard set. (The PRC Government has some standards on the > appearances of characters of several bitmap sizes.) * I agree with you that it is not a good idea to have a title (of a * document) which does not fully represent the content. However, * The document does says that the supplement should be use until * GB2312-80 is being revised. I think GB should has make the * supplement as seperate GB document. > One may write an HBF file to specify a font (i.e., its bitmap files) > based on a particular variant of GB2312-80 encoded characters. > > That's all. > > HBF/cclib*.hbf are for fonts conformed to GB2312-80 which is published > in 1980. GB2312-80 is well defined and the official publication can be > obtained from the Standard Bureau (publishing house) in Beijing (if the > stock still lasts). * so is GB6345.1-86 and GB6345.2-86! (well, may be not *well defined* but * at least *officially defined*) > > mcpong > /Simon From khsc@synoptics.com Mon Oct 4 12:39:50 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA05464; Mon, 4 Oct 93 12:39:50 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA26393; Mon, 4 Oct 93 10:36:54 PDT Received: by taichi (4.1/2.0N) id AA05493; Mon, 4 Oct 93 10:36:53 PDT Message-Id: <9310041736.AA05493@taichi> Date: Mon, 4 Oct 93 10:36:53 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: GB6345 Status: RO > From simpson@math.psu.edu Mon Oct 4 09:45:18 1993 > Received: from synoptics.com (pobox) by taichi (4.1/2.0N) > id AA05367; Mon, 4 Oct 93 09:45:17 PDT > Received: from leibniz.math.psu.edu by synoptics.com (4.1/SMI-4.1) > id AA25994; Mon, 4 Oct 93 09:45:15 PDT > Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id MAA24457; Mon, 4 Oct 1993 12:46:45 -0400 > From: Stephen G Simpson > Received: from localhost by boole.math.psu.edu id ; Mon, 4 Oct 1993 12:46:44 -0400 > Date: Mon, 4 Oct 1993 12:46:44 -0400 > Message-Id: <199310041646.MAA25104@boole.math.psu.edu> > To: Simon Chow > In-Reply-To: <9310041639.AA05356@taichi> > Subject: Re: GB6345 > Status: R > > OK, thanks for the explanation. I don't have any immediate need > for this, but it is interesting. I don't think there is any way that > HBF (as presently defined) can accommodate half-width characters. > Maybe you should bring this up as a topic for discussion on the > soft-authors list? > > -- Steve Simpson > Well, I have not been thing about adding anything to HBF spec. although it is in theory possible to add a property line to specify this attribute with given code ranges: HBF_START_HALF_WIDTH_RANGES 1 HBF_HALF_WIDTH_RANGES 0xAAA1-0xABC0 HBF_END_HALF_WIDTH_RANGES I would like to see something similar to this happen on the next release of HBF spec. After all the reason for GB to formulate the GB6345 supplemnet was because some people think that the half-width characters are usefull. There is no reason why we should dis-allow this in the HBF specfication. One can always ignore it if he/she does not want to be concern with this new attribute. For now, I only intend to handle this in my program only. That is, my program will have to have explicte knowlege regarding a certain code range in a specific code set. |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. From jamesxu@meceng.coe.neu.edu Mon Oct 4 17:13:34 1993 Return-Path: Received: from nuhub.dac.neu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA10573; Mon, 4 Oct 93 17:13:34 CDT Received: from meceng.coe.neu.edu (meceng-9.coe.neu.edu) by neu.edu (PMDF V4.2-13 #4985) id <01H3Q2OYOBBK91Y5D9@neu.edu>; Mon, 4 Oct 1993 18:14:49 EST Received: from splinter.coe.neu.edu by meceng.coe.neu.edu (4.1/SMI-4.1) id AA04479; Mon, 4 Oct 93 18:11:12 EDT Date: Mon, 04 Oct 1993 18:11:12 -0400 (EDT) From: jamesxu@meceng.coe.neu.edu (James Z. Xu) Subject: mailing list To: soft-authors@ifcss.org Message-Id: <9310042211.AA04479@meceng.coe.neu.edu> X-Envelope-To: soft-authors@ifcss.org Content-Transfer-Encoding: 7BIT Status: RO I would like to join this discussion and also like to take some steps in remodify my own programs with some advanced techniques. Thanks. From khsc@synoptics.com Mon Oct 4 18:28:47 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA11560; Mon, 4 Oct 93 18:28:47 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA28833; Mon, 4 Oct 93 16:25:51 PDT Received: by taichi (4.1/2.0N) id AA06422; Mon, 4 Oct 93 16:25:50 PDT Message-Id: <9310042325.AA06422@taichi> Date: Mon, 4 Oct 93 16:25:50 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: 64x64 bitmap Status: RO I have a timely piece of information, someone (I don't have the original posting anymore) mention that we are not likely to see more publicly available 24, 48 or 64 bit chinese character bit map! Here is one: coding scheme: CCCII (Chinese Character Code for Information Interchange?) format: 64 x 64 bit map size: 42 MB uncompressed, 12 MB compressed (ZIP) location: nctuccca:/Chinese/CCDB CCCII is well documented (unlike BIG5). information regarding the CCCII can also be obtained from the same directory. I understand that CCCII has been endosed by ROC government, may be we should consider allowing it in HBF as well. Just a thought! If we do, then it may be easy for someone to come up with a utility to map CCCII into BIG5 or GB and vise versa, or create a BIG5 (GB) 64x64 bitmap from the CCCB bitmap. |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= #include From mcpong@cs.ust.hk Mon Oct 4 21:21:11 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA13655; Mon, 4 Oct 93 21:21:11 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA00846; Tue, 5 Oct 93 10:19:43 HKT Date: Tue, 5 Oct 93 10:19:43 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310050219.AA00846@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: GuoBiao & GB6345 Status: RO I think it's important to clarify the difference between a "coding standard" and a "standard on the shapes of glyphs", so that the readers are not confused. Guobiao = ~{国家标准~} guojia biao, meaning "National Standard" PRC government has many "guobiao", e.g. about size of bolts and nuts, etc. GB2312-80 is a ***HANZI CODING STANDARD*** -- the title is ~{信息交换用汉字编码字符集基本集~} -- (my direct translation to English) is "character set, basic set, of Chinese character encoding for information interchange" There are other PRC government ***HANZI CODING STANDARDs***, say, for traditional Chinese characters. =========== GB6345.1-86 is a ***standard on the shapes of glyphs*** -- the title is ~{信息交换用32x32点阵字模集~} -- (my direct translation to English) is "32x32 bitmap glyph set for information interchange" GB6345.2-86 is a standard on the DATA of the glyphs of GB6345.1-86 -- the title is ~{信息交换用32x32点阵字模集 数据集~}. ^^^^^^ the bitmap DATA SET for GB6345.1-86 They include some glyphs not defined in GB2312-80, and use some "code points" (as some writers use such term) from the "unused encoding space" of GB2312-80 to encode those glyphs. There are other PRC governemnt published glyph sets of various bitmap sizes; e.g., GB5007.1-85 is ~{信息交换用24x24点阵字模集~}. GB5007.2-85 is ~{信息交换用24x24点阵字模集 数据集~}. data set GB5199.1-85 is ~{信息交换用15x16点阵字模集~}. GB5199.2-85 is ~{信息交换用15x16点阵字模集 数据集~}. data set =========== > From khsc@synoptics.com Tue Oct 5 01:59:15 1993 > Subject: Re: GB6345 > > ... > If I can > squeece out more time, I will create a gb6345.16 file and the associate ^^^^^^^^^ > HBF file for the 16 bit fonts. So, if one really makes a size-16 glyph set conforming to the PRC government standard, one should conform to GB5199.1-85 & GB5199.2-85. =========== Probably the question orginates from: > From khsc@synoptics.com Tue Oct 5 01:59:15 1993 > Subject: Re: GB6345 > > ... > My original reason for creating gb6345.24 (bitmap file for gb6345) was > to to allow me to write a HP laser printer printing program which allows > mix GB and ascii code. I am sure that anyone who has attempt the effort > has encounter the same problem. GB is two byte long and ASCII is one byte > long, it is only natural that a Chinese ideogram occupy twice the width of > an ASCII character. now the problem is that GB bitmap is defined in an > externl file such as cclib.*24, and ASCII font is not. I need an ASCII > bitmap file that is half the width of the GB bitmap file. > ... Whether we really should allow an HBF file to specify variable width glyphs in the same HBF file? I'd oppose the idea. To do mixed width char output (say, for ASCII char & hanzi), one can use 2 HBF files, one for the ASCII bitmaps and one for the hanzi bitmaps. (The bitmaps may be in the same or different bitmap files.) The kuochiao 16x16 hanzi bitmaps & 16x14 symbol bitmaps are similar in nature, and F.F.Lee has posted a way to tackle this problem. Please see Lee's earlier posting. mcpong From mcpong@cs.ust.hk Mon Oct 4 23:02:05 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA14941; Mon, 4 Oct 93 23:02:05 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA01098; Tue, 5 Oct 93 12:00:37 HKT Date: Tue, 5 Oct 93 12:00:37 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310050400.AA01098@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: env variable(s) for HBF Status: RO Now I have this thought about environment (env) variable for HBF: (1) Someone likes (or some system forces) to separate bitmap files from HBF files in different directories. This is the requirement. (2) Thus there should be 2 env variables, one for the bitmap files, and another for HBF files. (3) If (2) is accepted, then there can be (& should be) NO bitmap-file-directory information in HBF files. This would make HBF files independent of directory information and more portable across different systems. ====== Searching for an HBF file and the referenced bitmap file(s) can be defined to be on a FIRST MATCH principle. The API implementation should find an HBF file given as parameter in some directory specified by the HBF_FILE_PATH env variable, then any bitmap files referenced in the HBF file would be found in some directory specified by the HBF_BITMAP_PATH env variable. The name HBFPATH is not clear enough, because it doesn't say whether the specified paths hold HBF files and/or the bitmap files, and whether a directory in the paths should hold either or both HBF files & bitmap files. So, I use HBF_FILE_PATH & HBF_BITMAP_PATH in the previous paragraph. In case HBF files & bitmap files are in the same directory, the directory would be stated in both HBF_FILE_PATH & HBF_BITMAP_PATH. mcpong From lee@simd.Stanford.EDU Tue Oct 5 01:14:50 1993 Return-Path: Received: from simd.Stanford.EDU by ifcss.org (4.1/IFCSS-Mailer) id AA16099; Tue, 5 Oct 93 01:14:50 CDT Received: by simd.Stanford.EDU (5.65/DEC-Ultrix/4.3) id AA06256; Mon, 4 Oct 1993 23:13:01 -0700 Date: Mon, 4 Oct 1993 23:13:01 -0700 From: lee@simd.Stanford.EDU (Fung Fung Lee) Message-Id: <9310050613.AA06256@simd.Stanford.EDU> To: mcpong@cs.ust.hk Cc: soft-authors@ifcss.org In-Reply-To: Dr. Man-Chi PONG's message of Tue, 5 Oct 93 10:19:43 HKT <9310050219.AA00846@cs.ust.hk> Subject: Re: GuoBiao & GB6345 Status: RO >To do mixed width char output (say, for ASCII char & hanzi), >one can use 2 HBF files, one for the ASCII bitmaps and one >for the hanzi bitmaps. (The bitmaps may be in the same or >different bitmap files.) Or one HBF file for hanzi and something else for ASCII, be it mono-spaced Courier, or variable-spaced Helvetica or Times Roman. This is probably the case for printing mixed English-Chinese files on laserprinters with outline English fonts and bitmapped Chinese fonts. [[ e.g. hz2ps ]] >The kuochiao 16x16 hanzi bitmaps & 16x14 symbol bitmaps are >similar in nature, and F.F.Lee has posted a way to tackle this >problem. Please see Lee's earlier posting. > >mcpong Not quite the same. The BIG5 symbols and hanzi are effectively 16x14. For some strange reason, KuoChiao padded two blank bottom rows to the symbols so that they become 16x16. Anyway, for the solution, please ftp the relevant files kc*.* from ifcss.org:software/fonts or /incoming. -FFL From xiaofei Tue Oct 5 01:35:02 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA16257; Tue, 5 Oct 93 01:35:02 CDT Date: Tue, 5 Oct 93 01:35:02 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9310050635.AA16257@ifcss.org> To: soft-authors@ifcss.org Subject: Re: env variable(s) for HBF Status: RO :The API implementation should find an HBF file given as parameter :in some directory specified by the HBF_FILE_PATH env variable, then :any bitmap files referenced in the HBF file would be found in some :directory specified by the HBF_BITMAP_PATH env variable. : Please excuse my silliness. Does HBF mean 'Hanzi Bitmap Font'? If so, then HBF_BITMAP means 'Hanzi-Bitmap-Font_BITMAP' :-) From mcpong@cs.ust.hk Tue Oct 5 01:55:40 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA16350; Tue, 5 Oct 93 01:55:40 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA01549; Tue, 5 Oct 93 14:54:03 HKT Date: Tue, 5 Oct 93 14:54:03 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310050654.AA01549@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: Re: env variable(s) for HBF Status: RO -- "xiaofei@ifcss.org (XiaoFei Wang)" wrote on 1993 Oct 5 (Tue): > Does HBF mean 'Hanzi Bitmap Font'? If so, then > HBF_BITMAP means 'Hanzi-Bitmap-Font_BITMAP' :-) An Hanzi Bitmap Font (HBF) refers to a bitmap font. The HBF file is the specification file specifying the properties of the font. The file of HBF bitmaps is the file containing the bitmaps of the font. :-) mcpong From rap@doc.ic.ac.uk Tue Oct 5 03:21:28 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA16804; Tue, 5 Oct 93 03:21:28 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0ojuC9-00070PC; Mon, 4 Oct 93 18:59 BST Message-Id: Date: Mon, 4 Oct 93 18:59 BST From: Ross Paterson To: g53150@sakura.kudpc.kyoto-u.ac.jp, soft-authors@ifcss.org Subject: Re: soft-authors_discussion_list_and_HBF_file Status: RO Christian Wittern writes: > Now I would like the creators of this standard to consider an extension > in three ways: > 1. Inclusion of Unicode. Unicode as a subset of ISO 604*** is certainly > the code standard of the future. It is certainly desirable to have > shareware and PD software supporting Unicode as soon as possible. > For the CJK area, I think this could be done with a minimal Latin > support and th Unicode Han-Character range, with covers ca. 21000 > Characters from BIG5, GB, JIS, KSC ... (details can be found at > unicode.com:pub/mapping-tables/cjkrefx.doc). Actually, it supports Unicode now: I keep all my text in the FSS-UTF encoding of Unicode/ISO-10646 (of which ASCII is a special case). I only use the Latin-1, CJK punctuation and UniHan subsets of Unicode. I cobbled together 16x16 and 24x24 fonts for most of the last two from GB, BIG-5, JIS and KSC fonts. Here's part of the HBF file I use for printing (with my own HBF-based program): HBF_START_FONT 1.0 HBF_CODE_SCHEME UniCode FONT UniHan24 ... HBF_START_BYTE_2_RANGES 1 HBF_BYTE_2_RANGE 0x00-0xFF HBF_END_BYTE_2_RANGES HBF_START_CODE_RANGES 2 COMMENT CJK Auxilliary HBF_CODE_RANGE 0x3000-0x3029 ../bitmaps/UniCJK24.bin 0 COMMENT CJK Unified "Ideographs" (UniHan) HBF_CODE_RANGE 0x4E00-0x9FA5 ../bitmaps/UniHan24.bin 0 HBF_END_CODE_RANGES HBF_END_FONT The editor I use is an X version of the Plan-9 editor "sam" (which I rather like, by the way), from research.att.com:/dist/sam/. The main thing that is missing is a convenient input method (instead of piping text through a filter). > 2. Considering a scheme for font-compression. With 16*16 GB-fonts, this > hardly matters, but a 64*64 UniHan font would uncompressed be about > 10 MB - hardly something for everybody's harddisk. This might be incompatible with HBF's assumption of fixed size bitmaps. > 3. Support for CCCII. I know, this might be difficult, so I just ask your > opinion. I would love to see usable and free CCCII applications as > soon as possible. This would seem to require changing HBF to support 3-byte codes. The change in the file format would be presumably be BYTE_3_RANGEs, as proposed by Fung Fung Lee. How would we distinguish 2- from 3-byte codes? (by the presence or absence of BYTE_3_RANGE? What is absence of BYTE_2_RANGEs intended to mean?) In the C interface, the main change would be that characters would have to be longs (big enough for ISO-10646 too) instead of unsigned shorts. Ross From ucc02au@sunmail.lrz-muenchen.de Tue Oct 5 05:30:28 1993 Return-Path: Received: from cd1.lrz-muenchen.de by ifcss.org (4.1/IFCSS-Mailer) id AA17659; Tue, 5 Oct 93 05:30:28 CDT Received: from sunserver.lrz-muenchen.de by cd1.lrz-muenchen.de id SMTP-0012cb14c66018758; Tue, 5 Oct 93 11:28:54 +0100 Received: from sun3.lrz-muenchen.de by sunserver.lrz-muenchen.de (4.1/SMI-4.1) id AA07471; Tue, 5 Oct 93 11:28:53 +0100 Received: by sun3.lrz-muenchen.de (4.1/SMI-4.1) id AA04623; Tue, 5 Oct 93 11:28:53 +0100 From: ucc02au@sunmail.lrz-muenchen.de (HU Bo) Message-Id: <9310051028.AA04623@sun3.lrz-muenchen.de> Subject: HBF standard for high definition fonts - data compression To: soft-authors@ifcss.org (soft authors) Date: Tue, 5 Oct 1993 11:28:52 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 636 Status: RO For fonts of 24x24 or fewer points, the problem of disk space required is not as serious as that for fonts of higher definitions. To adopt those fonts into HBF standard, an additional field specifying "compression method" should be used for each bitmap file (!). Using a simple data compression, I am able to reduce the disk usage of a 64x64 font to 1.4-1.7 MB (or 40-50%) and make it delieverable on a single 1.44 MB disk in LHARCed or ZIPped format. Another point is that we should start with the definition of an "HVF" standard, for vectorell or outlined fonts, since these fonts begin to become available (and affordable). Bo From xiaokun@stats.gla.ac.uk Tue Oct 5 05:51:58 1993 Return-Path: Received: from hillhead.cent.gla.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA17875; Tue, 5 Oct 93 05:51:58 CDT Received: from govan.cent.gla.ac.uk by jess.glasgow.ac.uk with SMTP (PP) id <04643-0@jess.glasgow.ac.uk>; Tue, 5 Oct 1993 11:50:09 +0100 Received: from central.cent.gla.ac.uk by govan.cent.gla.ac.uk; Tue, 5 Oct 93 11:50:05 BST Received: from jupiter.stats.stats.gla.ac.uk ([130.209.4.72]) by central.cent.gla.ac.uk; Tue, 5 Oct 93 11:50:03 BST From: Xiaokun Zhu Date: Tue, 5 Oct 93 11:52:32 BST Message-Id: <6332.9310051052@jupiter.stats.stats.gla.ac.uk> To: soft-authors@ifcss.org Subject: Re: HBF standard for high definition fonts - data compression Status: RO ucc02au@de.lrz-muenchen.sunmail (HU Bo) writes: > Another point is that we should start with the definition of an "HVF" > standard, for vectorell or outlined fonts, since these fonts begin to > become available (and affordable). I agree with this point. But does anyone have idea how the Type 1 Font (Postscript) and True Type Font (MS Windows) works? I mean how to translate this compress format into plain text format (like Type 3 font). There are so many outline ASCII font in Type 1 or True Type format. ---xiaokun From yawei Tue Oct 5 10:10:17 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA20483; Tue, 5 Oct 93 10:10:17 CDT Date: Tue, 5 Oct 93 10:10:17 CDT From: yawei (Ya-Gui Wei) Message-Id: <9310051510.AA20483@ifcss.org> To: soft-authors Subject: Re: env variables Status: RO Perhaps HBF_FILE_PATH could be HBF_HEADER_PATH? I would perceive "HBF File" to include the bitmap files as well. For reason of brevity I think I prefer just "HBF" and "HZFONT", the former for the header and the later for the bitmap. Regarding the potential ambiguity (put forth by Steve Simpson et al.) where multiple bitmap fonts with the same name exists, optional pathnames could always be specified in the HBF files, which is analogous to how the PATH variable works on unix. Ya-Gui From simpson@math.psu.edu Tue Oct 5 10:38:30 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA20844; Tue, 5 Oct 93 10:38:30 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id LAA06137; Tue, 5 Oct 1993 11:37:03 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 5 Oct 1993 11:37:02 -0400 Date: Tue, 5 Oct 1993 11:37:02 -0400 Message-Id: <199310051537.LAA26422@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: HBF_BITMAPS_PATH Status: RO M. C. Pong has proposed that HBF implementations employ two environment variables, HBF_FILES_PATH and HBF_BITMAPS_PATH, containing lists of directories to search for HBF files and HBF bitmaps respectively. I am not clear on some aspects of this proposal. Perhaps MC could clarify? A very important question is, what would be the default value of HBF_BITMAPS_PATH if it were not defined in the environment? In Ross's current implementation, HBFPATH defaults to the current directory. But I am not sure that this would be a good default for HBF_BITMAPS_PATH. One reason I think this question is very important is that, under DOS, the amount of environment space available is very limited. The DOS default is ridiculously low, something like 256 bytes for all environment strings. It can be increased by putting a special command into CONFIG.SYS, but this special command is undocumented and not widely known. So, under DOS, many users will not be able to define HBF_BITMAPS_PATH. Therefore, it is important to choose a reasonable default. Failing this, we must give users another way to tell applications where to find bitmaps. Another group of questions. In Ross's current implementation, HBF files can optionally contain directory information telling where to find bitmaps. Would such information be disallowed, or would it remain as a documented option? What would happen if such information were present? Would it override the information in HBF_BITMAPS_PATH? Would it be interpreted relative to the directories in HBF_BITMAPS_PATH? Would it be ignored? Would it result in an error? About the DOS environment problem, I was already thinking about this problem with respect to HBFPATH, but I didn't raise an objection here because I felt that there had to be some way to tell programs where to find HBF files, and the environment seemed like a good way. But for bitmap files, we already have another way, namely put the bitmap directory information into the HBF files. So I have some reservations about HBF_BITMAPS_PATH. -- Steve Simpson From khsc@synoptics.com Tue Oct 5 13:15:09 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA22832; Tue, 5 Oct 93 13:15:09 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA02279; Tue, 5 Oct 93 11:12:08 PDT Received: by taichi (4.1/2.0N) id AA06671; Tue, 5 Oct 93 11:12:07 PDT Message-Id: <9310051812.AA06671@taichi> Date: Tue, 5 Oct 93 11:12:07 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: GB6345 Status: RO > From mcpong@cs.ust.hk Mon Oct 4 19:43:48 1993 > > > > ... > > If I can > > squeece out more time, I will create a gb6345.16 file and the associate > ^^^^^^^^^ > > HBF file for the 16 bit fonts. > > So, if one really makes a size-16 glyph set conforming to the PRC government > standard, one should conform to GB5199.1-85 & GB5199.2-85. > Well, point taken, the file name should have been gb6345suplement.16 > =========== > To do mixed width char output (say, for ASCII char & hanzi), > one can use 2 HBF files, one for the ASCII bitmaps and one > for the hanzi bitmaps. (The bitmaps may be in the same or > different bitmap files.) > > The kuochiao 16x16 hanzi bitmaps & 16x14 symbol bitmaps are > similar in nature, and F.F.Lee has posted a way to tackle this > problem. Please see Lee's earlier posting. > I agree this is doable, allowing this in HBF simply means I have one less evnironment variable I have to sepcify (or one less piece of information I have to hard code into my program). In either case I agree that it is less messy to use a seperate HBF. This should take care of my programing problem. However, this should not prevent us for from specifying new properties of the bitmap file in HBF. Half width charaters are real, today, we do not have a sigle bitmap file available on the net should not prevent us from getting ready to accomodate this new attribute. I understand that we can purchase the bitmap file specified in GB6345 from a company in Beijing. If someone have this file, he/she should be able to use HBF to fully describ the property of the bitmap file, it would be very nice if the single bitmap file can be described in a single HBF file. |\/\/\/| =============================== | | ==================================== | | (o)(o) | | Simon Chow C _) UUCP: att!synoptics.com!schow | | SynOptics Communication Inc. | ,___| INTERNET: schow@synoptics.com | | 4401 Great America Pkwy, | / Voice: +1 (408) 764-1327 | | Santa Clara, CA 95052-8185 /____\ Fax: +1 (408) 988-5525 | ============================================================================= #include From mcpong@cs.ust.hk Wed Oct 6 02:10:50 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA01000; Wed, 6 Oct 93 02:10:50 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA03186; Wed, 6 Oct 93 15:09:19 HKT Date: Wed, 6 Oct 93 15:09:19 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310060709.AA03186@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: Re: env variables Status: RO -- "Stephen G Simpson " wrote on 1993 Oct 5 (Tue): > M. C. Pong has proposed that HBF implementations employ two > environment variables, HBF_FILES_PATH and HBF_BITMAPS_PATH, containing > lists of directories to search for HBF files and HBF bitmaps > respectively. > > I am not clear on some aspects of this proposal. Perhaps MC could > clarify? The main concept is to separate the paths for HBF-spec-file (HBF-file) & bitmap file. If this is acceptable, the details of what are the names for the environment variables for the paths can be finalized later. > A very important question is, what would be the default value of > HBF_BITMAPS_PATH if it were not defined in the environment? In Ross's > current implementation, HBFPATH defaults to the current directory. > But I am not sure that this would be a good default for > HBF_BITMAPS_PATH. | Yidao Cai at cai@neurophys.wisc.edu sent a mail to me: | | I think you should allow people to specify one path only. If the first | (HBF_FILE_PATH) is set while the one for bitmap is not, by default, it | equals to HBF_FILE_PATH. What do you think ? I think this suggestion is very reasonable. That is, an API implementation can get the value of HBF_FILE_PATHS first. Moreover, unspecified HBF_FILE_PATHS can default to the current directory. Then following Yidao's suggestion, unspecified HBF_BITMAP_PATHS will be current directory as well. > One reason I think this question is very important is that, under DOS, > the amount of environment space available is very limited. The DOS > default is ridiculously low, something like 256 bytes for all > environment strings. It can be increased by putting a special command > into CONFIG.SYS, but this special command is undocumented and not > widely known. So, under DOS, many users will not be able to define > HBF_BITMAPS_PATH. Therefore, it is important to choose a reasonable > default. Failing this, we must give users another way to tell > applications where to find bitmaps. Ya-Gui has some suggestion on short DOS environment variables. See below. > Another group of questions. In Ross's current implementation, HBF > files can optionally contain directory information telling where to > find bitmaps. Would such information be disallowed, or would it > remain as a documented option? What would happen if such information > were present? Would it override the information in HBF_BITMAPS_PATH? > Would it be interpreted relative to the directories in > HBF_BITMAPS_PATH? Would it be ignored? Would it result in an error? These are really issues not yet defined clearly in the standard document v1.0. Now we are fine-tuning what the "bitmapFileName" (& any "path"?) attribute in the HBF_CODE_RANGE line means. For portability of HBF-spec-files across platforms, a pure filename will be good enough; and the path information can be isolated into environment variable. If we really adopt this stand, then we could (IMHO, I would say "should") disallow path information in HBF-spec-file. The bitmapFile will be found in the HBF_BITMAP_PATHS or the default path (according to the searching rule described above, and on a "first match" basis -- the "first match" principle will resolve the ambiguity of duplicated filenames.) Any extra information in the HBF_CODE_RANGE line would be flagged as error. BTW, comment on which directories (or origins) of the bitmap files can be put in COMMENT lines, but COMMENTs are ignored by the API implementation. === comparison: === If we really allow path information and delimiter, Steve's sample questions illustrated that they are not so cleanly answered, even if we can eventually draw up a set of rules to answer them. =================== -- "yawei@ifcss.org (Ya-Gui Wei)" also suggests the use of shorter name. - - For reason of brevity I think I prefer just "HBF" and "HZFONT", - the former for the header and the later for the bitmap. These are good suggestion of names. They are short. "HBF" is simple enough to refer to HBF-files (i.e., HBF-spec-files). "HZFONT" also decouples the bitmap files from HBF-files, as the bitmap files can be used independent of HBF-files. - Regarding the potential ambiguity (put forth by Steve Simpson - et al.) where multiple bitmap fonts with the same name exists, - optional pathnames could always be specified in the HBF files, - which is analogous to how the PATH variable works on unix. I think allowing path information in the HBF_CODE_RANGE lines can cause confusion, and the way to resolve the final path for the bitmap filenames would be more complicated than the benefit it brought, comparing with using HZFONT (previously called HBF_BITMAP_PATHS) environment variable. - Ya-Gui mcpong ~{庞民治~} From simpson@math.psu.edu Wed Oct 6 08:21:42 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA02400; Wed, 6 Oct 93 08:21:42 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id JAA15537; Wed, 6 Oct 1993 09:20:19 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Oct 1993 09:20:18 -0400 Date: Wed, 6 Oct 1993 09:20:18 -0400 Message-Id: <199310061320.JAA27689@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: what is a reasonable default for HBF_BITMAP_PATH ? Status: RO >From Yidao Cai and M C Pong: > | I think you should allow people to specify one path only. If the first > | (HBF_FILE_PATH) is set while the one for bitmap is not, by default, it > | equals to HBF_FILE_PATH. What do you think ? > I think this suggestion is very reasonable. > > That is, an API implementation can get the value of HBF_FILE_PATHS first. > Moreover, unspecified HBF_FILE_PATHS can default to the current directory. > Then following Yidao's suggestion, unspecified HBF_BITMAP_PATHS will be > current directory as well. This proposal means that if neither path is specified, both will default to the current directory. I see a serious problem with this proposal. Suppose that neither path is specified. Let's say some HBF header files and bitmaps are in C:\CHINESE\FONTS, and suppose the current directory is C:\. If the application program does handle = HBF_openfont("C:\CHINESE\FONTS\CCLIB24.HBF"); HBF_getbitmap(handle, code, buffer); then it will find the header file, but it won't find the bitmaps, because the bitmaps are not in the current directory! I think a better proposal would be to make HBF_BITMAP_PATH default to the directory containing the HBF header file. In other words, if HBF_BITMAP_PATH is not specified in the environment, then the HBF implementation expects the bitmaps for each HBF header file to be in the same directory as that particular header file. (But I also think that the HBF header file itself should be able to override this, by specifying pathnames for the bitmap files. As in the current implementation, these pathnames can be absolute, or they can be relative to the directory containing the header file.) -- Steve Simpson From simpson@math.psu.edu Wed Oct 6 09:06:16 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA03174; Wed, 6 Oct 93 09:06:16 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id KAA15824; Wed, 6 Oct 1993 10:04:51 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Oct 1993 10:04:50 -0400 Date: Wed, 6 Oct 1993 10:04:50 -0400 Message-Id: <199310061404.KAA27724@boole.math.psu.edu> To: soft-authors@ifcss.org Status: RO MC Pong writes: > If we really adopt this stand, then we could (IMHO, I would say "should") > disallow path information in HBF-spec-file. > > The bitmapFile will be found in the HBF_BITMAP_PATHS or the default path > (according to the searching rule described above, and on a "first match" > basis -- the "first match" principle will resolve the ambiguity of > duplicated filenames.) > > Any extra information in the HBF_CODE_RANGE line would be flagged as error. This means that there would be no way to tell HBF_getbitmap where to find the bitmaps, except through the HBF_BITMAP_PATH environment variable. As I mentioned before, I see a serious problem with this proposal. DOS provides an environment space of only 160 bytes. The total length of *all* environment strings cannot exceed 160 bytes! This includes the PATH and PROMPT strings as well all as environment strings used by applications. The difficulty with MC Pong's proposal is that a long string of directories called HBF_BITMAP_PATH would exceed this space. This will happen even if the name of the environment variable is shortened from HBF_BITMAPS_PATH to HZFONT. When the user tries to set the HZFONT variable, a DOS error message will result. If an HBF API implementation is to be usable on DOS, it has to provide a another way to specify the location of bitmaps, in addition to or instead of an environment variable. Ross's current implementation does this by allowing the HBF header file to specify bitmap directory information. The above proposal by MC Pong would disallow this. I think a better way would be to keep the flexibility of the current implementation (bitmap directory information specified in header files) supplemented by an HBF_BITMAP_PATH environment variable. Users can then choose which method or combination of methods they want to use. A sophisticated DOS user could use HBF_BITMAP_PATH, because such a user would know how to increase the size of his environment space (an undocumented CONFIG.SYS command). The only caveat is that, if HBF_BITMAP_PATH is not specified in the environment, it should default to something reasonable. Of course all of this will be irrelevant for most users, because most users will store the bitmaps for a given HBF header file in the same directory as that header file. But a good API implementation should provide other options. -- Steve Simpson From qzhou@fuchsia.att.com Wed Oct 6 15:26:38 1993 Received: from research.att.com (ninet.research.att.com) by ifcss.org (4.1/IFCSS-Mailer) id AA07654; Wed, 6 Oct 93 15:26:38 CDT Received: by research.att.com; Wed Oct 6 16:25 EDT 1993 Received: by fuchsia (920330.SGI/910805.SGI) for @research.att.com:soft-authors@ifcss.org id AA10617; Wed, 6 Oct 93 16:25:12 -0400 Return-Path: Date: Wed, 6 Oct 93 16:25:12 -0400 From: qzhou@fuchsia.research.att.com (Qiru Zhou) Message-Id: <9310062025.AA10617@fuchsia> To: soft-authors@ifcss.org Subject: DOS env. size Status: RO Steve Simpson writes: >DOS provides an environment space of only 160 bytes. The total length >of *all* environment strings cannot exceed 160 bytes! This includes >the PATH and PROMPT strings as well all as environment strings used by >applications. ... It is not true for *all* DOS environment stack. 160 bytes is for one environment variable, such as PATH, etc. You can use environment configuration statement SHELL to enlarge the stack. for example SHELL=c:\command.com /P /E 1024 will give you 1024 bytes for env. stack (The bytes number can be 160 to 32767, the defaut is 256). I have a very large env. stack to put MKS unix like environment. Although it is not verg practical to have a very long path name string in MS-DOS environment. -Qiru Zhou From simpson@math.psu.edu Wed Oct 6 15:50:33 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA08335; Wed, 6 Oct 93 15:50:33 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id QAA19367; Wed, 6 Oct 1993 16:49:10 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Oct 1993 16:49:08 -0400 Date: Wed, 6 Oct 1993 16:49:08 -0400 Message-Id: <199310062049.QAA28158@boole.math.psu.edu> To: soft-authors@ifcss.org In-Reply-To: <9310062025.AA10617@fuchsia> Subject: DOS env. size Status: RO Qiru Zhou writes: > You can use environment > configuration statement SHELL to enlarge the stack. for example > SHELL=c:\command.com /P /E 1024 will give you 1024 bytes for env. > stack (The bytes number can be 160 to 32767, the defaut is 256). According to my DOS manual, the default is 160, not 256. Also, the above command to enlarge the environment is correct, but it is not documented. For instance, my DOS manual says that the SHELL command in CONFIG.SYS takes no switches. The /E switch is mentioned under the discussion of how to use COMMAND.COM as a secondary command processor. The manual does not point out that this same switch can be used in CONFIG.SYS to enlarge the environment permanently. Anyway, my main point was that a very small percentage of DOS users know how to enlarge the environment space. This is certainly true. > I have a very large env. stack to put MKS unix like environment. > Although it is not verg practical to have a very long path name > string in MS-DOS environment. I have my environment configured to 2048 bytes so that I can use various GNU-like utilities. But the great majority of DOS users don't do anything like this -- they simply use the default of 160 bytes. -- Steve Simpson From simpson@math.psu.edu Wed Oct 6 18:03:11 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA10717; Wed, 6 Oct 93 18:03:11 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id TAA20222; Wed, 6 Oct 1993 19:01:48 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Oct 1993 19:01:46 -0400 Date: Wed, 6 Oct 1993 19:01:46 -0400 Message-Id: <199310062301.TAA28278@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: DOS environment space Status: RO > From: qzhou@fuchsia.research.att.com (Qiru Zhou) > > Steve Simpson writes: > > DOS provides an environment space of only 160 bytes. The total length > > of *all* environment strings cannot exceed 160 bytes! This includes > > the PATH and PROMPT strings as well all as environment strings used by > > applications. ... > It is not true for *all* DOS environment stack. 160 bytes is for one > environment variable, such as PATH, etc. Sorry, no. The 160 byte limit is for the *total* length of *all* environment strings! Hard to believe, but true. If your PATH is 100 bytes and your PROMPT is 20 bytes and you have set a few other environment variables (for applications like ProComm Plus), you will not be able to set any more environment variables. If you try, you will get an error message, "Out of environment space". Try it, you will see. From mcpong@cs.ust.hk Wed Oct 6 21:57:37 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA13265; Wed, 6 Oct 93 21:57:37 CDT Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA00478; Thu, 7 Oct 93 10:56:10 HKT Date: Thu, 7 Oct 93 10:56:10 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9310070256.AA00478@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: HBF env variable(s) Status: RO I understand Steve's concern of DOS environment variable space. BTW, the installation document of any DOS-based application (even a simple "README" file) can tell the user to edit/add a line in CONFIG.SYS to increase the environment variable space. IMHO, the issue is: how important is it to have portable HBF-spec-files which is independent of the bitmap-file-path information? If the portability issue is not important (including probable editing of the HBF_CODE_RANGE lines in HBF-spec-files when installing them in any new system platform), then it is fine to have path information in the "bitmapFileName" attribute in the line: HBF_CODE_RANGE firstCode-lastCode bitmapFileName offset Others may like to give their opinions. That would help to settle the issue. -- m c From lee@simd.Stanford.EDU Thu Oct 7 03:41:01 1993 Return-Path: Received: from simd.Stanford.EDU by ifcss.org (4.1/IFCSS-Mailer) id AA15643; Thu, 7 Oct 93 03:41:01 CDT Received: by simd.Stanford.EDU (5.65/DEC-Ultrix/4.3) id AA08423; Thu, 7 Oct 1993 01:39:37 -0700 Date: Thu, 7 Oct 1993 01:39:37 -0700 From: lee@simd.Stanford.EDU (Fung Fung Lee) Message-Id: <9310070839.AA08423@simd.Stanford.EDU> To: soft-authors@ifcss.org In-Reply-To: Dr. Man-Chi PONG's message of Thu, 7 Oct 93 10:56:10 HKT <9310070256.AA00478@cs.ust.hk> Subject: *** HBF call for vote *** (Was: HBF env variable(s)) Status: RO > Others may like to give their opinions. That would help to > settle the issue. > >-- m c Yes, I think the HBF header path and HBF bitmap path issue should be settled. I now favor the solution as recently implemented by Ross, i.e., only one environment variable for HBF header path --- HBFPATH. I will give an additional argument in favor of this solution. Suppose there are two different versions of cclib.16 (in fact there are!), ie., two different files with the same "short" filename, residing in two different directories, say, /dir1, and /dir2. h1.hbf points to /dir1/cclib.16 while h2.hbf points to /dir2/cclib.16. This is easy to achieve in the current solution as in Ross' implementation. However, if HBF_BITMAP_PATH is used, and, say, HBF_BITMAP_PATH=/d1:/d2, and h1.hbf points to cclib.16 while h2.hbf points to cclib.16, then HBF_BITMAP_PATH will always point to /d1/cclib.16, although what h2.hbf really needs is /d2/cclib.16! Hence, HBF_BITMAP_PATH actually limits flexibility in this case. Well, do you still want HBF_BITMAP_PATH? = = = = = = = = = = Anyway, I think the important thing in the near future is to encourage more software developers to support HBF. From some recent postings, it is clear that reluctance to support HBF by some developers is at least due to their misunderstandings of the HBF format. If you don't like all these setenv stuff, do it your own way. In Ross' implementation, if you call HBF_OpenFont() with a full path name, you can effectively nullify the effect of HBFPATH. (Ross, correct me if I am wrong.) As in other standards work, at least 50% is "politics". Here's my advice for those who don't want to support BIG5 (GB) in their GB (BIG5) only software: Parse the line beginning with HBF_CODE_SCHEME. If it doesn't correspond to the coding scheme you'd like to support, refuse to use the HBF file and report errors. Similary, if your software can't handle non-square bitmap dimensions, refuse to use the HBF file and report errors. .... Even if U only support HBF to this level, it's already a big step forward. In my humble opinion, whether HBF will fulfill its promise depends on how wide spread it will be accepted. With the availability of a good HBF API implementation, such as Ross', for free inclusion, and the fact that several programs have demonstrated how easy it is to use the API, can we CO-OPERATE to solve this hanzi bitmap font file sharing problem once and for all? HBF may not be your perfect solution. But HBF is the best solution currently available. As freeware developers who are interested in allowing users to share fonts easily rather than protecting your own proprietory fonts, would you sign-up to support HBF-1.0 as soon as possible, say, by sending mail to xiaofei@ifcss.org or to this list? This list was orginally created for the sole purpose of coming up with the design, implemenation and promotion of an open standard for hanzi bitmap font file sharing. Can we have some feedbacks from the silent audience? To be concrete, I'd like to call for a vote. ------------------------------------------------------------------------- 1. What is the name of your current software? 2. As a software developer, would you support HBF in your software ? A. Yes, already B. Yes, soon C. Yes, later D. Undecided E. No ------------------------------------------------------------------------- As a courtesy to those who have spent their spare time on HBF, could each of you on this list send your answers to the above questions to this list, soft-authors@ifcss.org ? Best regards, Fung F. Lee P.S. Thanks for Xiaofei for setting up this discussion list and his generosity in donating his free time for frequent updating HBF related files on the ifcss.org archive site. This is probably my last posting to soft-authors@ifcss.org on the topic of HBF. Enough has been said and I've updated my programs (hz2ps, hzview) to support HBF. Whose turn? From wang@cps201.cps.cmich.edu Thu Oct 7 08:28:36 1993 Return-Path: Received: from cps201.cps.cmich.edu ([141.209.20.222]) by ifcss.org (4.1/IFCSS-Mailer) id AA17302; Thu, 7 Oct 93 08:28:36 CDT Received: by cps201.cps.cmich.edu (4.1/SMI-920923bjw); id AA02114; Thu, 7 Oct 93 09:27:13 EDT Date: Thu, 7 Oct 1993 09:23:47 -0400 (EDT) From: Wei Wang Subject: Re: DOS environment space To: Stephen G Simpson Cc: soft-authors@ifcss.org In-Reply-To: <199310062301.TAA28278@boole.math.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 6 Oct 1993, Stephen G Simpson wrote: > Sorry, no. The 160 byte limit is for the *total* length of *all* > environment strings! Hard to believe, but true. If your PATH is 100 > bytes and your PROMPT is 20 bytes and you have set a few other > environment variables (for applications like ProComm Plus), you will > not be able to set any more environment variables. If you try, you > will get an error message, "Out of environment space". Try it, you > will see. This is true and false. I don't remember if 160 is the default DOS environment variable space, but you can change that with a shell paramenter (add something like 'shell=c:\command.com /E256 /P' in your CONFIG.SYS file). I have to say that I'm not totally positive about the switch usage of COMMAND.COM, but this is the way to do it. Try it out or read a DOS manual. Good luck. Wang Wei [MS CS, Central Michigan University [1601 S. Washington Ct., Apt O-13, Mt.Pleasant, MI 48858 [517.774.5842 (Home) 517.774.3987 (Office) From @vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it Thu Oct 7 08:59:40 1993 Return-Path: <@vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it> Received: from vm.cnuce.cnr.it by ifcss.org (4.1/IFCSS-Mailer) id AA17495; Thu, 7 Oct 93 08:59:40 CDT Received: from ICIL64.CILEA.IT by vm.cnuce.cnr.it (IBM VM SMTP V2R2) with BSMTP id 7134; Thu, 07 Oct 93 14:57:57 MET Received: from ICIL64.CILEA.IT by ICIL64.CILEA.IT (PMDF V4.2-11 #2920) id <01H3U2OJQG5S9ULOEJ@ICIL64.CILEA.IT>; Thu, 7 Oct 1993 14:58:01 MET-DST Date: Thu, 7 Oct 1993 14:58:01 MET-DST From: CBOGANG@icil64.cilea.it Subject: Re: *** HBF call for vote *** To: soft-authors@ifcss.org Message-Id: <01H3U2OJRSDU9ULOEJ@ICIL64.CILEA.IT> X-Envelope-To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: RO >From: IN%"lee@simd.Stanford.EDU" >Subj: *** HBF call for vote *** (Was: HBF env variable(s)) > >...... > >This list was orginally created for the sole purpose of coming up >with the design, implemenation and promotion of an open standard for >hanzi bitmap font file sharing. Can we have some feedbacks from the silent >audience? To be concrete, I'd like to call for a vote. I have been a silent audience. Now I vote: >------------------------------------------------------------------------- >1. What is the name of your current software? The only software I uploaded to ifcss.org is ChPad, a chinese file browser for MS Windows. >2. As a software developer, would you support HBF in your software ? >A. Yes, already >B. Yes, soon >C. Yes, later >D. Undecided >E. No F. If I wrote a chinese program under DOS, I would support HBF in it. I am afraid I will not write any chinese program for DOS. > ...... There are many ways to write a chinese program in MS Windows. You can do it by reading in the bitmap pattern from a HANZI BITMAP FONT file and draw points on the client area of a window. It is possible to support HBF in this kind of programming. The *font* (with extension .FON) defined in MS Windows is really a DLL that can contain more than one bitmap resouce (.FNT) file(s). I have converted some HANZI BITMAP FONT to .FON files. The HBF file can be helpful in converting, for example, CCLIB.16 to GBJ16.FON. When I go to write program, I use the .FON file, the HBF has no more help. I always hope to see some discussion on the standardization of chinese font for MS Windows. May I say it is still "silent", if not forgotten. Regards, Tian Bogang cbogang@icil64.cilea.it From ucc02au@sunmail.lrz-muenchen.de Thu Oct 7 12:30:28 1993 Return-Path: Received: from cd1.lrz-muenchen.de by ifcss.org (4.1/IFCSS-Mailer) id AA20055; Thu, 7 Oct 93 12:30:28 CDT Received: from sunserver.lrz-muenchen.de by cd1.lrz-muenchen.de id SMTP-0012cb451da007656; Thu, 7 Oct 93 18:28:58 +0100 Received: from sun3.lrz-muenchen.de by sunserver.lrz-muenchen.de (4.1/SMI-4.1) id AA23916; Thu, 7 Oct 93 18:28:57 +0100 Received: by sun3.lrz-muenchen.de (4.1/SMI-4.1) id AA18749; Thu, 7 Oct 93 18:28:56 +0100 From: ucc02au@sunmail.lrz-muenchen.de (HU Bo) Message-Id: <9310071728.AA18749@sun3.lrz-muenchen.de> Subject: *** HBF call for vote *** To: soft-authors@ifcss.org (soft authors) Date: Thu, 7 Oct 1993 18:28:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2524 Status: RO > > However, if HBF_BITMAP_PATH is used, and, say, HBF_BITMAP_PATH=/d1:/d2, and > h1.hbf points to cclib.16 while > h2.hbf points to cclib.16, > ... > Hence, HBF_BITMAP_PATH actually limits flexibility in this case. > Well, do you still want HBF_BITMAP_PATH? > A simple solution is to define HBF_ROOT_PATH so that all bitmap and header files may be placed in some subdirectories RELATIVE to this root_path. This variable can be defined in DOS' environment or kept in some application's ini file. According to my experiences, entries in PATH and other env settings cause always far more troubles than entries in an application's own ini file. Remember: many users have never tried to go thru their DOS manual and only learnt to enter WORD (f.i.) to write their texts. Cammands like "CD" cause already troubles, since the structure of a directores tree is not as obvious as we (programmers) think. Now to the "vote": > ------------------------------------------------------------------------- > 1. What is the name of your current software? ShiYong CCDOS, Munich System, JitsuYou JKDOS (Chinese and Japanese DOS extensions), EasyWin (Chinese wordprocessor and dictionary package), WinPsc (Chinese PostScript pre-interpreter and spooler under Windows) > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No F.: Not yet. The screen drivers are written in 86-asm to reduce memory requirement and enheighten performance. It is fairly difficault to implement parsers using 86-asm. For printing interfaces, since data compression of bitmaps and outlined glyph structures are used, it is now not possible to use HBF format (correct me if I am wrong!). ------------------------------------------------------------------------- I think, to solve the problem of inter-platform and inter-vendor sharing of Chinese font resource, a more object oriented concept is required. Data decompression and bitmap inter- or extrapolation must be seen as a part of a font (groups) together with seeking of a character by its code under some given code schema. Under DOS, it may be implemented as a interrupt, under Windows as a DLL and under all platforms as a library (better: C source). Otherwise, forgive me, it is more easily (and efficient) to write some everything-to-everything font converter or simplely rename the files (thinking of the painfull example of two cclib's with accidentially identical name). Best regards, Bo From jiang Thu Oct 7 13:20:42 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA20927; Thu, 7 Oct 93 13:20:42 CDT Date: Thu, 7 Oct 93 13:20:42 CDT From: jiang (Yuan Jiang) Message-Id: <9310071820.AA20927@ifcss.org> To: soft-authors Subject: Re: *** HBF call for vote *** Status: RO I prefer having a HBFDIR or any name to define the directory of the header files, but it should be defaulted as the current directory if nothing defined. This gives DOS users a chance to save environment space. There is no perfect solution. Maybe we can list the top choices and vote on them. From Ricky.Yeung@Eng.Sun.COM Thu Oct 7 13:30:33 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA21095; Thu, 7 Oct 93 13:30:33 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19263; Thu, 7 Oct 93 11:28:49 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06765; Thu, 7 Oct 93 11:28:50 PDT Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA22274; Thu, 7 Oct 93 11:28:51 PDT Date: Thu, 7 Oct 93 11:28:51 PDT From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9310071828.AA22274@hk.Eng.Sun.COM> To: CBOGANG@icil64.cilea.it Cc: soft-authors@ifcss.org In-Reply-To: CBOGANG@icil64.cilea.it's message of Thu, 7 Oct 1993 14:58:01 MET-DST <01H3U2OJRSDU9ULOEJ@ICIL64.CILEA.IT> Subject: Re: *** HBF call for vote *** Status: O > From: CBOGANG@icil64.cilea.it > > >From: IN%"lee@simd.Stanford.EDU" > >Subj: *** HBF call for vote *** (Was: HBF env variable(s)) > > > >...... > > > >This list was orginally created for the sole purpose of coming up > >with the design, implemenation and promotion of an open standard for > >hanzi bitmap font file sharing. Can we have some feedbacks from the silent > >audience? To be concrete, I'd like to call for a vote. > > I have been a silent audience. Now I vote: > > >------------------------------------------------------------------------- > >1. What is the name of your current software? > > The only software I uploaded to ifcss.org is ChPad, a chinese file > browser for MS Windows. > > >2. As a software developer, would you support HBF in your software ? > >A. Yes, already > >B. Yes, soon > >C. Yes, later > >D. Undecided > >E. No > > F. If I wrote a chinese program under DOS, I would support HBF in it. > I am afraid I will not write any chinese program for DOS. I would say if you write a Chinese software that you handle the bitmap display/output by yourself, you would support HBF by either using the sample implemenation or write your own to read HBF files. > There are many ways to write a chinese program in MS Windows. You can > do it by reading in the bitmap pattern from a HANZI BITMAP FONT file > and draw points on the client area of a window. It is possible to > support HBF in this kind of programming. > The *font* (with extension .FON) defined in MS Windows is really a DLL > that can contain more than one bitmap resouce (.FNT) file(s). I have > converted some HANZI BITMAP FONT to .FON files. The HBF file can be > helpful in converting, for example, CCLIB.16 to GBJ16.FON. When I go > to write program, I use the .FON file, the HBF has no more help. So do you have a tool to convert HBF font to .FON and .FNT files? Would you like to share it? Then MS Windows users can use all the bitmap fonts with HBF files! Ross wrote a tool to convert hbf files to bdf for X Windows. If your software is running on an OS that has a font manager, I think the best way to support (use) HBF is through a converter. > I always hope to see some discussion on the standardization of chinese > font for MS Windows. May I say it is still "silent", if not forgotten. I am not quite sure what did you mean by "standardization of chinese font for MS Windows." MS Windows has its own "standard" format for font. Did you mean an open standard for all the vendors? -Ricky From xiaokun@stats.gla.ac.uk Thu Oct 7 14:10:54 1993 Return-Path: Received: from hillhead.cent.gla.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA21693; Thu, 7 Oct 93 14:10:54 CDT Received: from milkyway.stats.gla.ac.uk by jess.glasgow.ac.uk with SMTP (PP) id <22844-0@jess.glasgow.ac.uk>; Thu, 7 Oct 1993 20:08:37 +0100 From: Xiaokun Zhu Date: Thu, 7 Oct 93 20:11:09 BST Message-Id: <18783.9310071911@milkyway.stats.stats.gla.ac.uk> To: soft-authors@ifcss.org Subject: Re: *** HBF call for vote *** (Was: HBF env variable(s)) Status: O > 1. What is the name of your current software? CCTeach, cxterm-NewFace > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No F.: Both sotware do not access bitmap Font directly. > ... > fonts with HBF files! Ross wrote a tool to convert hbf files to bdf for > X Windows. where can I got the convert software (HBF ==> bdf)? ---xiaokun From Ricky.Yeung@Eng.Sun.COM Thu Oct 7 14:21:14 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA21868; Thu, 7 Oct 93 14:21:14 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA28619; Thu, 7 Oct 93 12:19:37 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11960; Thu, 7 Oct 93 12:19:25 PDT Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA22537; Thu, 7 Oct 93 12:19:27 PDT Date: Thu, 7 Oct 93 12:19:27 PDT From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9310071919.AA22537@hk.Eng.Sun.COM> To: xiaokun@stats.gla.ac.uk Cc: soft-authors@ifcss.org In-Reply-To: Xiaokun Zhu's message of Thu, 7 Oct 93 20:11:09 BST <18783.9310071911@milkyway.stats.stats.gla.ac.uk> Subject: Re: *** HBF call for vote *** (Was: HBF env variable(s)) Status: O > > fonts with HBF files! Ross wrote a tool to convert hbf files to bdf for > > X Windows. > > where can I got the convert software (HBF ==> bdf)? It's bundled with Ross' package in ifcss.org. -Ricky From charles.wang@infores.com Thu Oct 7 14:57:34 1993 Return-Path: Received: from kaze (kaze.infores.com) by ifcss.org (4.1/IFCSS-Mailer) id AA22492; Thu, 7 Oct 93 14:57:34 CDT Received: by kaze id AA16247 (5.65c/IDA-1.4.4 for soft-authors@ifcss.org); Thu, 7 Oct 1993 15:49:05 -0400 Date: Thu, 7 Oct 1993 15:49:05 -0400 From: Charles Wang Message-Id: <199310071949.AA16247@kaze> To: soft-authors@ifcss.org Subject: %I for sscanf in C Cc: cqw@kaze Status: O Hi I recently tried to build the Ross Paterson's HBF implementation on my PC. However I found an interesting "bug" in the hbf.c file. There is a line of C code as sscanf(line, "HBF_CODE_RANGE %I-%I %s %I %s", ....) ; where %I is not considered as a valid conversion specification under my SunOS C compiler nor does it under Microsoft C. But the program runs fine under UNIX while generates errors under DOS/Windows. My ANSI C book was just borrowed by one of my friend so ... I changed the "%I" to "%li" and the code runs fine now on the PC. Could someone please tell me whether this is an intended use or it is a bug? Maybe it is valid under some C compiler? Thanks. -- Charles Q. Wang Information Resources, Inc (617) 290-4500 ext 7952 200 Fifth Ave charles.wang@infores.com Waltham, MA 02154 From yawei Thu Oct 7 16:39:30 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA24271; Thu, 7 Oct 93 16:39:30 CDT Date: Thu, 7 Oct 93 16:39:30 CDT From: yawei (Ya-Gui Wei) Message-Id: <9310072139.AA24271@ifcss.org> To: charles.wang@infores.com, soft-authors Subject: Re: %I for sscanf in C Status: O ANSI C (k&r2) listed %i as a scanf conversion string, but not %I. Regarding the call for "vote" (seems more like a poll to me), I would like to eventually support HBF in ZWDOS, but have not spent much time on it yet. Next version may or may not support HBF, depending on time economics. From @vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it Fri Oct 8 05:24:30 1993 Return-Path: <@vm.cnuce.cnr.it:CBOGANG@icil64.cilea.it> Received: from vm.cnuce.cnr.it by ifcss.org (4.1/IFCSS-Mailer) id AA01194; Fri, 8 Oct 93 05:24:30 CDT Received: from ICIL64.CILEA.IT by vm.cnuce.cnr.it (IBM VM SMTP V2R2) with BSMTP id 8712; Fri, 08 Oct 93 11:22:48 MET Received: from ICIL64.CILEA.IT by ICIL64.CILEA.IT (PMDF V4.2-11 #2920) id <01H3V9G6U2GG9ULQE0@ICIL64.CILEA.IT>; Fri, 8 Oct 1993 11:22:50 MET-DST Date: Fri, 8 Oct 1993 11:22:50 MET-DST From: CBOGANG@icil64.cilea.it Subject: Re: RE: *** HBF call for vote *** To: soft-authors@ifcss.org Message-Id: <01H3V9G6V51E9ULQE0@ICIL64.CILEA.IT> X-Envelope-To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: O >From: IN%"Ricky.Yeung@Eng.Sun.COM" 7-OCT-1993 19:29:22.77 >Subj: RE: *** HBF call for vote *** > > ........ > >I would say if you write a Chinese software that you handle the bitmap >display/output by yourself, you would support HBF by either using the >sample implemenation or write your own to read HBF files. You are right. Only that I don't handle the bitmap display by myself in my Ms Windows program. Or I should say: I have tried to avoid to handle the bitmap directly in my program. Windows GDI and font engine do it. I DO handle the bitmap file when I convert the bitmap file to MS Windows .FNT file. See below. > > The *font* (with extension .FON) defined in MS Windows is really a DLL > > that can contain more than one bitmap resouce (.FNT) file(s). I have > > converted some HANZI BITMAP FONT to .FON files. The HBF file can be > > helpful in converting, for example, CCLIB.16 to GBJ16.FON. When I go > > to write program, I use the .FON file, the HBF has no more help. > >So do you have a tool to convert HBF font to .FON and .FNT files? Would >you like to share it? Then MS Windows users can use all the bitmap >fonts with HBF files! Ross wrote a tool to convert hbf files to bdf for >X Windows. I wrote a program to convert some 16*16 GB bitmap font to Windows .FNT files. I am thinking to write a general program, using HBF :-), to convert any HBFable bitmap font to .FNT files. I'd like to share that with all of you. The .FNT file is a Windows font resource. The specification of .FNT file can be found in: Programmer's Reference, Volume 4: Resource, page 49 This book is included in MS Windows SDK 3.1 package. >From .FNT file to .FON is really a process to build a DLL. It is a DLL without any code and data but contains resources. You can also find the steps and example of building a .FON file from .FNT files in: Guide to Programming, charpter 18, page 385 It is also included in MS Windows SDK 3.1 package. The really useful information starts at page 432. I repeat: the HBF can be quite helpful in building a .FON file from a chinese bitmap font file. When you have the .FON file, you have no way (or I don't how) to use the HBF in your program. Usually, to use the .FON file in your program, you do: *) add the .FON file to Windows font table. *) get the handles of logical fonts. *) call GDI functions to select the font handle and output text. So, how do you use the HBF file now? Here we do need some information about the famous "gap" in GB. When build the .FON file, you can decide to include or not the blank bitmap between AAA1 to AFFE. Then you should tell the programmers who use the .FON file what is the gap. For example, the CH16.FON from Mr. Wang Wei has no gap, and the GBJ16.FON and GBF16.FON in ChPad 1.2 do have a gap between AAA1 to AEFE, totally 470 entry. Here we need something like HBF. >If your software is running on an OS that has a font manager, I think >the best way to support (use) HBF is through a converter. > > > I always hope to see some discussion on the standardization of chinese > > font for MS Windows. May I say it is still "silent", if not forgotten. > >I am not quite sure what did you mean by "standardization of chinese >font for MS Windows." MS Windows has its own "standard" format for >font. Did you mean an open standard for all the vendors? Yes, Ms Windows has its own format for font. That is for any ASCII, single byte font. We chinese have to devide a chinese bitmap font file into many .FNT files (by converting) and put all these .FNT file into a .FON file. Here we need some standard. For example, the "gap" I mentioned above, need to be described in open, standard way for programmers. Regards, Tian Bogang From guojin@iss.nus.sg Fri Oct 8 06:54:12 1993 Return-Path: Received: from bochap.iss.nus.sg by ifcss.org (4.1/IFCSS-Mailer) id AA01682; Fri, 8 Oct 93 06:54:12 CDT Received: from badger.iss.nus.sg by bochap.iss.nus.sg (4.1/SMI-4.1) id AA02399; Fri, 8 Oct 93 19:54:47+080 Message-Id: <9310081154.AA02399@bochap.iss.nus.sg> To: soft-authors@ifcss.org Cc: guojin@iss.nus.sg Subject: sub Date: Fri, 08 Oct 93 19:54:45 +0800 From: guojin@iss.nus.sg Status: O sub soft-authors GUO Jin From simpson@math.psu.edu Fri Oct 8 09:45:42 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA03663; Fri, 8 Oct 93 09:45:42 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id KAA15948; Fri, 8 Oct 1993 10:44:19 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 8 Oct 1993 10:44:18 -0400 Date: Fri, 8 Oct 1993 10:44:18 -0400 Message-Id: <199310081444.KAA04297@boole.math.psu.edu> To: soft-authors@ifcss.org In-Reply-To: <01H3V9G6V51E9ULQE0@ICIL64.CILEA.IT> Subject: Re: RE: *** HBF call for vote *** Status: O CBOGANG@icil64.cilea.it writes: > I am thinking to write a general program, using HBF :-), to convert > any HBFable bitmap font to .FNT files. I'd like to share that with > all of you. That would be most welcome. I hope you will do this. In a similar vein, Ross's hbftobdf program converts any HBF font to an X windows BDF font. And I have something called hbftopk, which converts an HBF font to TeX PK and TFM fonts (using Angus Duggan's pbmtopk routine). Hbftopk is still in a crude experimental stage, but it is usable now, available at math.psu.edu:/pub/simpson/chinese/hbf. > We chinese have to devide a chinese bitmap font file into many .FNT > files (by converting) and put all these .FNT file into a .FON file. > Here we need some standard. I had the same problem in hbftopk. Each TeX font holds only 256 characters. My solution is to put all the characters with a first byte into one TeX font, indexed by the second byte. In this way the fonts are convenient for use in Poor Man's Chinese TeX, math.psu.edu:/pub/simpson/chinese/pmc. -- S. Simpson From rap@doc.ic.ac.uk Fri Oct 8 12:46:50 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA06940; Fri, 8 Oct 93 12:46:50 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0olLsc-00070NC; Fri, 8 Oct 93 18:45 BST Message-Id: Date: Fri, 8 Oct 93 18:45 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: %I for sscanf in C Cc: charles.wang@infores.com, simpson@math.psu.edu Status: O Charles Wang writes: > I recently tried to build the Ross Paterson's HBF implementation on my > PC. However I found an interesting "bug" in the hbf.c file. There > is a line of C code as > > sscanf(line, "HBF_CODE_RANGE %I-%I %s %I %s", ....) ; > > where %I is not considered as a valid conversion specification under > my SunOS C compiler nor does it under Microsoft C. But the program > runs fine under UNIX while generates errors under DOS/Windows. My ANSI > C book was just borrowed by one of my friend so ... > > I changed the "%I" to "%li" and the code runs fine now on the PC. It seems you're right, according to my copy of Harbison&Steele. Another bug: hbftobdf also opens the HBF file directly, so it doesn't work with HBFPATH. I've added a call hbfFileName() so it can find out the real HBF filename, and now it appears to work. Both of these can wait till the next release, I think. From wang@cps201.cps.cmich.edu Fri Oct 8 17:04:29 1993 Return-Path: Received: from cps201.cps.cmich.edu (cps222.cps.cmich.edu) by ifcss.org (4.1/IFCSS-Mailer) id AA10904; Fri, 8 Oct 93 17:04:29 CDT Received: by cps201.cps.cmich.edu (4.1/SMI-920923bjw); id AA03780; Fri, 8 Oct 93 18:03:08 EDT Date: Fri, 8 Oct 1993 17:11:29 -0400 (EDT) From: Wei Wang Subject: Re: *** HBF call for vote *** To: Fung Fung Lee Cc: soft-authors@ifcss.org In-Reply-To: <9310070839.AA08423@simd.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Thu, 7 Oct 1993, Fung Fung Lee wrote: > Yes, I think the HBF header path and HBF bitmap path issue should be > settled. I now favor the solution as recently implemented by Ross, > i.e., only one environment variable for HBF header path --- HBFPATH. > I will give an additional argument in favor of this solution. > > Suppose there are two different versions of cclib.16 (in fact there are!), > ie., two different files with the same "short" filename, > residing in two different directories, say, /dir1, and /dir2. > h1.hbf points to /dir1/cclib.16 while > h2.hbf points to /dir2/cclib.16. > This is easy to achieve in the current solution as in Ross' implementation. > > However, if HBF_BITMAP_PATH is used, and, say, HBF_BITMAP_PATH=/d1:/d2, and > h1.hbf points to cclib.16 while > h2.hbf points to cclib.16, > then HBF_BITMAP_PATH will always point to /d1/cclib.16, > although what h2.hbf really needs is /d2/cclib.16! > > Hence, HBF_BITMAP_PATH actually limits flexibility in this case. > Well, do you still want HBF_BITMAP_PATH? Why do we definitely need a PATH environment variable here? An alternative approach would be using a profile. In Unix world, the convention is to use a specific file .rc ( is the software name, 'rc' stands for resource) in the home directory, for example, '.elmrc' for program 'elm'. In this file, a lot of initialization kind of stuff can be done, which has totally nothing to do with either the system itself nor any other software. In Microsoft Windows, the 'win.ini' file is always there for you. You can also use a private profile with a name like '.ini'. I personally believe this approach is better than the environment variables. For example, a file '.HBFrc' can be put either in the current working directory or the user's home directory. Every HBF supporting program can go to this file to find whatever info they want. They can even write their own stuff into this file. The MS Windows .ini profile format is a better choice in this case to support multi-reference of one profile. Each program can have its own "sections" with different "keywords" in each section to refer to different profile variables. As a programmer, an environment variable is not my preference. My point of con here is that every process in a Unix system will have to have a copy of all the environment variables. This is ok if the number of environment variables are kept limited. Otherwise it becomes kinda burden eventually. And for things like HBF, it's just a waste of memory for most of the other programs that has nothing to do with Chinese. > ------------------------------------------------------------------------- > 1. What is the name of your current software? My programs are Way v3.1.00 and wTalk v0.0, a Chinese input module for and a simple Chinese editor for MS Windows (for now :-), which I uploaded to ifcss.org. > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No I'm not supporting HBF right now. I agree with Mr Tian BoGang about this. At the current stage, HBF is mostly for Unix and DOS people (Correct me if I'm wrong). It still lacks the support one can get from Windows font API functions. I'm not sure if things like italic-ize, strike-out, underlining are included in the current HBF API implementation, but it's probably not as convenient as it could be using the standard Windows font API, if you are writing a Windows program. I'm not decided yet if I will support HBF in the future versions of my software, but it seems to be unlikely if I stick with MS Windows. > ------------------------------------------------------------------------- Regards. Wang Wei [MS CS, Central Michigan University [1601 S. Washington Ct., Apt O-13, Mt.Pleasant, MI 48858 [517.774.5842 (Home) 517.774.3987 (Office) From rwong@gucis.cit.gu.edu.au Mon Oct 11 03:57:46 1993 Return-Path: Received: from gucis.cit.gu.edu.au by ifcss.org (4.1/IFCSS-Mailer) id AA03871; Mon, 11 Oct 93 03:57:46 CDT Received: by gucis.cit.gu.edu.au id AA22654 (5.65c/IDA-1.4.4 for soft-authors@ifcss.org); Mon, 11 Oct 1993 18:51:05 +1000 Date: Mon, 11 Oct 1993 18:51:05 +1000 From: Richard Wong Message-Id: <199310110851.AA22654@gucis.cit.gu.edu.au> Apparently-To: soft-authors@ifcss.org Status: O -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To: soft-authors@ifcss.org Subject: Vote Hello About the vote from lee@simd.Stanford.EDU at Oct 7 > ------------------------------------------------------------------------- > 1. What is the name of your current software? > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No > ------------------------------------------------------------------------- My answer is this : 1. CDICT 2. B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------------------------------------------------- | 0000000000000000 | | 00000000000000000000000000 | | 00000000000000000000000000000000 | | 000000000000000000000000000000000000 | | 00000000000 0000000000000000 00000000000 | | 00000000000 00000000000000 00000000000 | | 0000000000000 0000000000000000 0000000000000 | | 0000000000000000000000000000000000000000000000 | | 0000000 0000000000000000000000000000000 000000 | | 00000 0000000000000000000000000000000000 00000 | | 000 000 000000000000000000000000000000 000 000 | | 00000000 00000000000000000000000000 00000000 | | 0000000000 000000000000000000000 000000000 | | 00000000000 00000000000000 00000000000 | | 00000000000 00000000000 | | 00000000000000000000000000000000 | | 00000000000000000000000000 | | 0000000000000000 | |_________________________________________________________________________| ------------------------------------------------------------------------- | From : Richard Wong (Sai Ho) ~{;FJ@:@~} | | : Bachelor of Informatics | | : Australia (QLD) Griffith University | | Email address : - < rwong@gucis.cit.gu.edu.au > | ------------------------------------------------------------------------- From simpson@math.psu.edu Mon Oct 11 07:59:38 1993 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA04823; Mon, 11 Oct 93 07:59:38 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.5/8.5) with ESMTP id IAA11433; Mon, 11 Oct 1993 08:58:13 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Mon, 11 Oct 1993 08:58:12 -0400 Date: Mon, 11 Oct 1993 08:58:12 -0400 Message-Id: <199310111258.IAA08183@boole.math.psu.edu> To: soft-authors@ifcss.org Subject: *** HBF call for vote *** (Was: HBF env variable(s)) Status: O The message below is from October 7. I intended it for the soft-authors list, but I'm not sure whether I posted it. So, if this is a duplicate posting, sorry, please ignore. ------ Fung Fung Lee writes: > Anyway, I think the important thing in the near future is to encourage more > software developers to support HBF. I completely agree, and Fung's posting has some very good suggestions on how developers can use HBF to make their lives easier, even if they don't want or need all of its features. > Can we have some feedbacks from the silent > audience? To be concrete, I'd like to call for a vote. > > ------------------------------------------------------------------------- > 1. What is the name of your current software? > > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No > ------------------------------------------------------------------------- Well, I haven't been exactly silent :-) but here is my "vote". 1. My current software: FLASH (version 1.5, at ifcss.org:/software/msdos/educational) HBFTOPK (experimental, at math.psu.edu:/pub/chinese/simpson/hbf/hbftopk) 2. Already using HBF in these packages. > This is probably my last posting to soft-authors@ifcss.org on the > topic of HBF. I would hope not! Fung's contributions to HBF have been crucial. After more experience is gained with HBF, it may be desirable to add features and I hope Fung and the other "heavy hitters" will participate. -- Steve Simpson From mcevilly@netcom.com Mon Oct 11 09:37:58 1993 Return-Path: Received: from netcom6.netcom.com by ifcss.org (4.1/IFCSS-Mailer) id AA05777; Mon, 11 Oct 93 09:37:58 CDT Received: by netcom6.netcom.com (5.65/SMI-4.1/Netcom) id AA22700; Mon, 11 Oct 93 07:37:12 -0700 From: mcevilly@netcom.com (Carlos McEvilly) Message-Id: <9310111437.AA22700@netcom6.netcom.com> Subject: Re: *** HBF call for vote *** To: soft-authors@ifcss.org Date: Mon, 11 Oct 93 7:37:11 PDT In-Reply-To: ; from "Wei Wang" at Oct 8, 93 5:11 pm X-Mailer: ELM [version 2.3 PL11] Status: O > 1. What is the name of your current software? Bamboo Helper, available as ifcss.org:/software/dos/education/bh101.zip > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No D., undecided. I would like to, since it sounds like a good idea, but don't know yet whether it will fit my future needs. - Carlos -- From rap@doc.ic.ac.uk Mon Oct 11 12:53:27 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA08032; Mon, 11 Oct 93 12:53:27 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0omRPf-00070OC; Mon, 11 Oct 93 18:52 BST Message-Id: Date: Mon, 11 Oct 93 18:52 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: *** HBF call for vote *** (Was: HBF env variable(s)) Status: O lee@simd.Stanford.EDU (Fung Fung Lee) writes: > Yes, I think the HBF header path and HBF bitmap path issue should be > settled. I now favor the solution as recently implemented by Ross, > i.e., only one environment variable for HBF header path --- HBFPATH. > I will give an additional argument in favor of this solution. > > Suppose there are two different versions of cclib.16 (in fact there are!), > ie., two different files with the same "short" filename, > residing in two different directories, say, /dir1, and /dir2. > h1.hbf points to /dir1/cclib.16 while > h2.hbf points to /dir2/cclib.16. > This is easy to achieve in the current solution as in Ross' implementation. > > However, if HBF_BITMAP_PATH is used, and, say, HBF_BITMAP_PATH=/d1:/d2, and > h1.hbf points to cclib.16 while > h2.hbf points to cclib.16, > then HBF_BITMAP_PATH will always point to /d1/cclib.16, > although what h2.hbf really needs is /d2/cclib.16! > > Hence, HBF_BITMAP_PATH actually limits flexibility in this case. > Well, do you still want HBF_BITMAP_PATH? A small variation on this argument: suppose I have an HBF file that works for me, and I tell someone else on my system about it. They add the relevant directories to their HBF_FILE_PATH and HBF_BITMAP_PATH, but if they already have a bitmap file in their HBF_BITMAP_PATH with the same name, the HBF file I recommended won't work for them. Or one of their HBF files that used to work will stop working, or will work differently. Of course a collision of HBF filenames would also cause a problem, but a less subtle one. With the HBFPATH version, the name of the bitmap file means whatever it means in the directory containg the HBF file. So an HBF file that is correct for me is correct for anyone else, once they've found it -- the HBF file is the sole gateway to the bitmaps. If your users can't handle directory names, they probably won't mind if you put all the HBF and bitmap files in the same directory, with simple names in the HBF files. That seems to be enough portability, without depriving more advanced users of the opportunity edit their HBF files if they wish. > If you don't like all these setenv stuff, do it your own way. > In Ross' implementation, if you call HBF_OpenFont() with a full path > name, you can effectively nullify the effect of HBFPATH. Yes, that's what happens now. Actually I think this ought to happen if you supply any directory information at all (even relative), just like PATH in Unix. So if you were to open "./xyzzy.hbf" then HBFPATH would be ignored. That's what I've done for the next release. From eric@coeus.ucsd.edu Mon Oct 11 12:56:46 1993 Return-Path: Received: from ucsd.edu by ifcss.org (4.1/IFCSS-Mailer) id AA08078; Mon, 11 Oct 93 12:56:46 CDT Received: from coeus.ucsd.edu by ucsd.edu; id AA11685 sendmail 5.67/UCSD-2.2-sun via SMTP Mon, 11 Oct 93 10:55:17 -0700 for soft-authors@ifcss.org Received: by coeus.ucsd.edu (AIX 3.2/UCB 5.64/4.03) id AA18399; Mon, 11 Oct 1993 10:55:51 -0700 Date: Mon, 11 Oct 1993 10:55:51 -0700 From: eric@coeus.ucsd.edu (Bo Yang) Message-Id: <9310111755.AA18399@coeus.ucsd.edu> To: soft-authors@ifcss.org Subject: HBF vote Status: O Hello! Just in case you've forgetten, this is one of the original contributors of the HBF idea speaking. :-) I've been quiet since Feng Feng Lee's first draft was out, hoping that rest of the contributors would polish it up soon. Here s my vote: > ------------------------------------------------------------------------- > 1. What is the name of your current software? ChiRK ( CHInese Reader for teKtronics-graphics compitable terminals) > 2. As a software developer, would you support HBF in your software ? > A. Yes, already > B. Yes, soon > C. Yes, later > D. Undecided > E. No > ------------------------------------------------------------------------- D. ChiRK is a very small package. It seems that HBF is becoming more and more complicated. I was planning to add hbf to next version, but if the amount of codes dealing with hbf exceeds half of the total, I will probably give up. :-) --- Bo Yang From Ricky.Yeung@Eng.Sun.COM Tue Oct 12 03:10:56 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA16224; Tue, 12 Oct 93 03:10:56 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AB11002; Tue, 12 Oct 93 01:09:25 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06730; Tue, 12 Oct 93 01:09:26 PDT Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA22772; Tue, 12 Oct 93 01:09:27 PDT Date: Tue, 12 Oct 93 01:09:27 PDT From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9310120809.AA22772@hk.Eng.Sun.COM> To: eric@coeus.ucsd.edu Cc: soft-authors@ifcss.org In-Reply-To: Bo Yang's message of Mon, 11 Oct 1993 10:55:51 -0700 <9310111755.AA18399@coeus.ucsd.edu> Subject: Re: HBF vote Status: O > > 2. As a software developer, would you support HBF in your software ? > > A. Yes, already > > B. Yes, soon > > C. Yes, later > > D. Undecided > > E. No > > ------------------------------------------------------------------------- > > D. > > ChiRK is a very small package. It seems that HBF is becoming more and more > complicated. I was planning to add hbf to next version, but if the amount of > codes dealing with hbf exceeds half of the total, I will probably give > up. :-) Just curious, why are you so concerned about the amount of work that you have to do to use HBF? It's supposed to be easy with a free API library! I would imagine several lines of changes to your current code would be suffice. Correct me if I'm wrong. -Ricky From eric@coeus.ucsd.edu Tue Oct 12 09:32:47 1993 Return-Path: Received: from ucsd.edu by ifcss.org (4.1/IFCSS-Mailer) id AA18158; Tue, 12 Oct 93 09:32:47 CDT Received: from coeus.ucsd.edu by ucsd.edu; id AA05025 sendmail 5.67/UCSD-2.2-sun via SMTP Tue, 12 Oct 93 07:31:24 -0700 for soft-authors@ifcss.org Received: by coeus.ucsd.edu (AIX 3.2/UCB 5.64/4.03) id AA15328; Tue, 12 Oct 1993 07:31:54 -0700 Date: Tue, 12 Oct 1993 07:31:54 -0700 From: eric@coeus.ucsd.edu (Bo Yang) Message-Id: <9310121431.AA15328@coeus.ucsd.edu> To: Ricky.Yeung@Eng.Sun.COM, eric@coeus.ucsd.edu Subject: Re: HBF vote Cc: soft-authors@ifcss.org Status: O >Just curious, why are you so concerned about the amount of work that you >have to do to use HBF? It's supposed to be easy with a free API >library! I would imagine several lines of changes to your current code >would be suffice. Correct me if I'm wrong. well, Ricky, I wasn't concerning about the work-load of adding HBF support. it's the over-all compactness of the codes. It dosn't LOOK righ to have, say, 150 lines of codes for all functions other than font libs and 300 lines of code for HBF alone, even if it's readily made. As I said it's "undecided", but I would certainly like to keep my codes small. There's no doubt on my support of HBF standard. just that I hve to think about the trade-offs. Regards! -- Bo From CAI@neurophys.wisc.edu Tue Oct 12 15:55:30 1993 Return-Path: Received: from neurophys.wisc.edu (mve.neurophys.wisc.edu) by ifcss.org (4.1/IFCSS-Mailer) id AA22937; Tue, 12 Oct 93 15:55:30 CDT Received: from VMSmail by neurophys.wisc.edu; Tue, 12 Oct 93 15:51 CST Message-Id: <23101215513191@neurophys.wisc.edu> Date: Tue, 12 Oct 93 15:51 CST From: CAI@neurophys.wisc.edu Subject: a simple 'API' To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O Hi, Everybody: I just put a simple HBF 'API' on ifcss.org:/incoming and it should be moved to /software/fonts/HBF or /software/fonts/d. The file name is cai_hbf_api.c. This 'API' (if it can be called an API at all) preforms the basic function of getting the bitmap of a character. It is intended to users who prefer an API with simpler functions and less codes, so that the codes for HBF API do not dominate the package. It should work on all platforms with minimum modification. Please send comments and report bugs to cai@neurophys.wisc.edu Yidao Cai From Ricky.Yeung@Eng.Sun.COM Tue Oct 12 19:05:01 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA24914; Tue, 12 Oct 93 19:05:01 CDT Received: from Eng.Sun.COM ([129.144.1.38]) by Sun.COM (4.1/SMI-4.1) id AA01180; Tue, 12 Oct 93 14:12:31 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14403; Tue, 12 Oct 93 14:11:01 PDT Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA28034; Tue, 12 Oct 93 14:11:09 PDT Date: Tue, 12 Oct 93 14:11:09 PDT From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9310122111.AA28034@hk.Eng.Sun.COM> To: soft-authors@ifcss.org Subject: Concerns on using HBF? (Was Re: HBF vote) Status: O > >Just curious, why are you so concerned about the amount of work that you > >have to do to use HBF? It's supposed to be easy with a free API > >library! I would imagine several lines of changes to your current code > >would be suffice. Correct me if I'm wrong. > > well, Ricky, I wasn't concerning about the work-load of adding HBF support. > it's the over-all compactness of the codes. It dosn't LOOK righ to have, say, > 150 lines of codes for all functions other than font libs and 300 lines of > code for HBF alone, even if it's readily made. As I said it's "undecided", > but I would certainly like to keep my codes small. > There's no doubt on my support of HBF standard. just that I hve to think > about the trade-offs. > > Regards! > > > -- Bo Are you talking about source code size or binary code size? For source code size, the user doesn't really care, and neither does the programmer. The HBF library is an independent library. Would one care about the size of the SOURCE of the C library? Xlib? On the other hand, is the size of the HBF library binary a concern? On my SparcStation, the size of hbf.o is about 9.7K. I could hardly imagine that a unix program like chirk would worry about the extra 10K of binary code size. I believe the binary of the hbf library on other platforms would be small as well. BTW, if I compile hbf.c with the optimization flag and strip its symbol table, it's only 4.7K. -Ricky From rap@doc.ic.ac.uk Fri Oct 15 11:54:38 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA01582; Fri, 15 Oct 93 11:54:38 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0onsOw-00070OC; Fri, 15 Oct 93 17:53 BST Message-Id: Date: Fri, 15 Oct 93 17:53 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: some UTF utilities Status: O I've placed a couple of programs in ifcss.org:/software/fonts/utils/utf-utils.tar.Z in case anyone wants to start playing with Unicode. These programs, and the others mentioned, are not exactly suitable for novice users. Here is the README: A few programs for manipulating Unicode/ISO-10646 text encoded in FSS-UTF (a.k.a. UTF-2 or just UTF): hexutf - convert 4-digit hexadecimal codes in an ASCII file to UTF. unicode - generate a table of UTF-encoded chars. utfascii - convert UTF text to ASCII bitmaps. utfps - convert UTF text to Postscript. Suitable 24-pixel fonts are in ifcss.org:/software/fonts/unicode24/. Currently only the Latin-1, CJK Auxiliary and UniHan ranges are handled. You'll also need files from ifcss.org:/software/fonts/HBF/c/hbf.tar.Z for the last two programs. For more information about - each program, see the header comments - UTF, see research.att.com:/dist/plan9man/09utf.ps.Z (Plan 9 is a research version of Unix.) - Unicode, see the above paper and various files at unicode.org and metis.com Other freely available stuff using the UTF encoding: research.att.com:/dist/sam/ an X windows port of the Plan 9 editor Sam. research.att.com:/dist/tcs.shar.Z translation between a wide variety of character codes (including the wrong Big-5). ftp.cs.su.oz.au:/matty/unicode/9term.tar.Z a Plan 9 terminal emulator for X (no curses). ftp.cs.su.oz.au:/matty/unicode/libXg.utf.fonts.tar.Z various fonts for Sam and 9term -- see also /matty/incoming/ -- Ross Paterson Department of Computing, Imperial College, London SW7 From ucc02au@sunmail.lrz-muenchen.de Fri Oct 29 07:38:44 1993 Return-Path: Received: from cd1.lrz-muenchen.de by ifcss.org (4.1/IFCSS-Mailer) id AA19017; Fri, 29 Oct 93 07:38:44 CDT Received: from sunserver.lrz-muenchen.de by cd1.lrz-muenchen.de id SMTP-0012cd10e76000110; Fri, 29 Oct 93 13:37:10 +0100 Received: from sun3.lrz-muenchen.de by sunserver.lrz-muenchen.de (4.1/SMI-4.1) id AA03284; Fri, 29 Oct 93 13:37:09 +0100 Received: by sun3.lrz-muenchen.de (4.1/SMI-4.1) id AA22758; Fri, 29 Oct 93 13:37:08 +0100 From: ucc02au@sunmail.lrz-muenchen.de (HU Bo) Message-Id: <9310291237.AA22758@sun3.lrz-muenchen.de> Subject: New version of software packages available To: soft-authors@ifcss.org (soft authors) Date: Fri, 29 Oct 1993 13:37:08 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2624 Status: O Forwarded message: >From ucc02au Fri Oct 29 13:32:26 1993 Subject: New version of software packages available To: ccnet-l@uga.bitnet (Chinese Network) Date: Fri, 29 Oct 1993 13:32:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2276 Dear netters, new versions (version 2.01) of following software packages are made ftp-able: ShiYong CCDOS: A Chinese DOS environment enables the usage of MS-WORD, WordPerfect dBASE and all Borland's language products for Chinese applications. Character and (new:) word oriented input. User's extensions to the input tables can be made on-the-fly. User defined input METHOD can be implemented WITHOUT any programming. Ca. 50000 entries in input tables, including toneless pinyin and graphic informations for an easy selection and quiry of characters of unknown pronounciation. Munich System: Aonther Chinese DOS environment (see above), but with intelligent sentence oriented pinyin input with or without tone. 32000 well sorted entries. Priorities of the entries can be changed on-the- fly. User's extensions to the input tables can be added and deleted as well. JitsuYou JKDOS: Japanese front end processor for DOS. It enables the usage of MS-WORD WordPrefect, dBASE and all Borland's language products for Japanese applications. As input table used: Wnn input table. User's extensions to the input table can be made on-the-fly. ------------------------------------------------------------------------ What is new? ------------------------------------------------------------------------ The version 2.01 of ShY, MSII and JY has following advantages in comparison to version 2.00 of ShY, MSII and version 1.00 of JY: 1) Including a SETUP, editing of .INI files no more neccessary. 2) Possibility of display four different fonts simultanously on display, for example, Chinese simplified, Chinese classical AND Japanese. 3) Possibility to view 7 bit GB/EUC-JIS files (MSB reset). 4) Some bugs eliminated. ------------------------------------------------------------------------ Availability ------------------------------------------------------------------------ As a DEMO version, which can be upgraded to a standard version when receiving a valid LICENCE code, all these three packages are ftp-able from ftp.lrz-muenchen.de[129.187.10.35], in /pub/culture/east-asia/sw/IBMPC/C/ShiYong.201, or .../C/MSII.201, or .../J/JitsuYou.201 Please send your questions, comments to ucc02au@sunmail.lrz-muenchen.de