From lee@umunhum.Stanford.EDU Mon Jul 19 23:39:22 1993 Return-Path: Date: Mon, 19 Jul 93 21:37:08 -0700 From: lee@umunhum.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: FYI: HBF software upgrade: hz2ps, hzview Status: RO Following is an article I've just posted to the newsgroups. -FFL Newsgroups: alt.chinese.text,soc.culture.hongkong,soc.culture.taiwan,soc.culture.china Subject: HBF software upgrade: hz2ps, hzview Summary: Expires: References: Sender: Followup-To: Distribution: Organization: Stanford University Keywords: The latest version of hz2ps and hzview are now available for anonymous ftp from ifcss.org. The biggest motivation for doing this upgrade is to support the recently emerged Hanzi Bitmap Font (HBF) file format. The idea is that with such as a flexible and powerful standard, future software developers and users should never have to worry about the fonts -- the myriad minor variations, the burden of distributing huge font files with software. If a program supports HBF, the user can always customize the font files including the file names to whatever the user likes, requiring no change to the program. Users can also easily create customized HBF header (text) files for their own (i.e. not public domain) bitmap font files that the author of the software has never seen. *************************************************************************** I encourage users of Chinese software to write (email) to the authors of their favorite software packages to support HBF, when the case applies. *************************************************************************** For the font files, see ifcss.org:/software/fonts. For the HBF document and sample HBF files, see ifcss.org:/software/fonts/HBF. The HBF API (Application Programming Interface) assumed in these programs is documented in the article "Hanzi Bitmap Font (HBF) File Format Standard Version 1.0", written by Dr. Man-Chi Pong of Hong Kong University of Science and Technology (mcpong@cs.ust.hk). The article can be obtained by ftp from ifcss.org:software/fonts/HBF as "HBF_std_v1.0". The HBF API implementation as in the files "hbf.c", "hbf.h", included in the hz2ps and hzview packages was written by Ross Paterson . ---------------------------------------------------------------------------- software: hz2ps version : 3.0 function: Convert hanzi (GB/BIG5) text to PostScript. Use HBF font files. ftp site: ifcss.org[129.107.1.155]:/software/unix/print filename: hz2ps-3.0.tar.Z hz2ps-3.0.readme author : Fung F. Lee ---------------------------------------------------------------------------- software: hzview version : 3.0 function: Display hanzi (GB/BIG5) text on dumb terminal. Use HBF font files. ftp site: ifcss.org[129.107.1.155]:/software/unix/viewer filename: hzview-3.0.tar.Z hzview-3.0.readme author : Fung F. Lee ---------------------------------------------------------------------------- Fung F. Lee From lee@umunhum.Stanford.EDU Tue Jul 20 01:50:00 1993 Return-Path: Date: Mon, 19 Jul 93 23:47:31 -0700 From: lee@umunhum.stanford.edu (Fung Fung Lee) To: rap@doc.ic.ac.uk Subject: hbftobdf, tester, ... Cc: soft-authors@ifcss.org Status: RO Ross, Thanks for your HBF implementation, I have released upgrades of hzview and hz2ps to support HBF font files. I'd strongly suggest you to submit your hbf package, including hbftobdf, to ifcss.org as a standalone package with document for inclusion into the catalogue file in ifcss.org:/software. I am aware of where your package now resides. Perhaps only some renaming is needed. Fung From lee@umunhum.Stanford.EDU Tue Jul 20 02:38:20 1993 Return-Path: Date: Tue, 20 Jul 93 00:36:01 -0700 From: lee@umunhum.stanford.edu (Fung Fung Lee) To: ftp-admin@ifcss.org Subject: .hbf files Cc: soft-authors@ifcss.org Status: RO Could you put the following .hbf files in /incoming into /software/fonts/HBF ? -rw-r----- 1 ftp 1731 Jul 20 07:23 Beijing16.hbf -rw-r----- 1 ftp 1721 Jul 20 07:23 Beijing24.hbf -rw-r----- 1 ftp 1766 Jul 20 07:23 cclib16.hbf -rw-r----- 1 ftp 1673 Jul 20 07:24 chinese16.hbf and the following bitmap file in /incoming into /software/fonts ? -rw-r----- 1 ftp 6016 Jul 20 07:28 cclib.16a Thanks. -FFL P.S. from cclib16.hbf: COMMENT cclib.16a provides additional bitmaps missing from cclib.16 ... HBF_CODE_RANGE 0xA8A1-0xA9FE cclib.16a 0 Careful users may have observed that the code ranges covered in {cclib.16} and {cclib*.24} (or {cclib.*24}) are not the same. If not, it's painfully obvious now. :-| From lee@umunhum.Stanford.EDU Tue Jul 20 03:04:04 1993 Return-Path: Date: Tue, 20 Jul 93 00:58:26 -0700 From: lee@umunhum.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org Subject: fonts and hbfcmp Status: RO I was told that cclibj_24.hbf and cclib_j24.hbf (and other pairs) were supposed to specify the same thing. Apparently it was not exactly the case when I tried Ross' hbfcmp program. Script started on Fri Jul 9 23:00:29 1993 1:simd> hbfcmp cclibj_24.hbf cclib_j24.hbf "cclib_j24.hbf", a6fe: extra bitmap "cclib_j24.hbf": 1 extra bitmaps Non-null bitmaps are 0.00468778% different. 2:simd> hbfcmp cclibk_24.hbf cclib_k24.hbf Non-null bitmaps are 0.00661908% different. 3:simd> hbfcmp cclibh_24.hbf cclib_h24.hbf Non-null bitmaps are 0.00797194% different. 4:simd> hbfcmp cclibf_24.hbf cclib_f24.hbf The fonts are identical. 5:simd> hbfcmp cclibb_24.hbf cclib_n24.hbf Non-null bitmaps are 0.00580413% different. If every program a user wants to run support HBF, then the user can choose to throw away whichever sets he (she) wants. Otherwise, he may be still have to stuck with both sets or more. I think one measure of success of solving the font format proliferation problem this group has seeked to address is the number of raw bitmap font files kept on ifcss.org. The smaller the better. Best regards, Fung F. Lee From mcpong@cs.ust.hk Wed Aug 11 22:02:07 1993 Return-Path: Date: Thu, 12 Aug 93 10:55:30 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: paper on HBF standard Status: RO Hi, Some of the Chinese software developers have been thinking of writing a paper on HBF to publicise this standard. There's "The ACM Journal of Standardization" (see back inside cover of Communications of the ACM 5/93). Its planned topics include: - Internationalization and Localization - Users and Standardization which are relevant to what we have done in writing the HBF standard. Here is a first outline of the organization of the paper. 1. Introduction 1.1 Background of font/encoding/... 1.2 Bitmap font 1.3 X11R5 BDF as a way to describe bitmap font 2. Why HBF? 2.1 Special feature of hanzi/kanji/hangul : same glyph size 2.2 Problem of BDF applied to hanzi. [much per-glyph information is duplicated] 2.3 New approach: per font attributes instead of per glyph attributes 3. HBF specification Highlights of HBF standard v1.0 4. Experience from writing the HBF standard 4.1 Some discussion we generate in the e-list. 4.2 Why we choose some but don't choose others. 5. HBF library interface 5.1 Current status 5.2 Possible extensions [[ Add in rotate, zoom, etc. We can develop a lib for HBF, i.e. we can rotate, zoom, ... for the user as if he were opening a real font. We can add that to the paper too. ]] 6. Applications and experience using HBF 7. Comparision to other work There is no related work as far as ygz and I know. But the paper is not complete without a comparision to others. e.g. how other systems solve the same problem, say, ETen's standard raw bitmap font and userfont format. 8. Conclusion 9. Acknowledgement All who has contributed to the discussion of the HBF standard. The following has shown interest to write some sections: ygz@cs.purdue.edu (Yongguang Zhang) section 2 mcpong@cs.ust.hk (Man-Chi Pong) section 3 lee@umunhum.stanford.edu (Fung Fung Lee) section 4 I could coordinate all the sections together; if necessary, I shall (have to :-) write any section not written by others. I suggest all who contribute to the paper would be co-authors of the paper. Please comment & show your interest in writing any section. I hope that the writing could be ready in two week's time. (There is a Chinese saying: "a long night, many (bad?) dreams". :-) Thanks. man-chi pong From simpson@math.psu.edu Fri Aug 20 14:59:26 1993 Return-Path: From: Stephen G Simpson Date: Fri, 20 Aug 93 15:54:44 -0400 To: CAI@neurophys.wisc.edu Cc: soft-authors@ifcss.org In-Reply-To: <23082014093309@neurophys.wisc.edu> Subject: kcchin24.* files Status: RO > I was told that the fonts in KC package are nice-looking. I tried > to write HBF files for those fonts but failed since I could not figure out > the organization of those fonts. I wonder if you can help. That is interesting. Until now there has not been any public domain set of 24x24 Big5 traditional character bitmaps. Maybe KC gives us this? That would be excellent. I don't have time right now to look at the KC font files, and if you didn't succeed in figuring them out, I probably wouldn't succeed either. One way out would be to create your own Big5 font files, using KC to extract the bitmaps from its own font files. KC has to display the bitmaps on the screen, so surely there must be a way to dump out the displayed bits to a file. In this way you could create Big5 fonts that would be probably almost as good as the ET fonts. -- S. Simpson From simpson@math.psu.edu Fri Aug 27 08:29:40 1993 Return-Path: From: Stephen G Simpson Date: Fri, 27 Aug 93 09:23:24 -0400 To: Huang Chih-Hsien Cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: <9308270807.AA02851@leibniz.math.psu.edu> Subject: CCDB database at nctuccca.edu.tw [140.111.3.21] Status: RO > It includes over 50,000 64*64 bitmap Chinese > character patterns. Wow! Are these bitmaps public domain? How hard would it be to extract 64x64 bitmap fonts for GB/simplified and Big5/traditional? It would be wonderful if these GB and Big5 fonts could be created and put into the public domain. I could use them for my own programs, and so could many other people. Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20 AT PSUVM FAX: +1 814 865-3735 From simpson@math.psu.edu Fri Aug 27 14:45:00 1993 Return-Path: From: Stephen G Simpson Date: Fri, 27 Aug 93 15:40:59 -0400 To: christian wittern Cc: soft-authors@ifcss.org In-Reply-To: <9308271435.AA04743@leibniz.math.psu.edu> Subject: CCDB database at nctuccca.edu.tw [140.111.3.21] Status: RO christian wittern writes: > > > It includes over 50,000 64*64 bitmap Chinese > > > character patterns. > > > > Wow! Are these bitmaps public domain? How hard would it be to > > extract 64x64 bitmap fonts for GB/simplified and Big5/traditional? It > > would be wonderful if these GB and Big5 fonts could be created and put > > into the public domain. I could use them for my own programs, and so > > could many other people. > > Extracting BIG5 Fonts would be very easy, I think. The database, > which comes with the fonts includes mappings for BIG5. > If I have time over the weekend, I'll try something and post it. > For GB it is not so straightforward, as the mappings are not included > in this package, so they would have to be acquired otherwise. > By the way, the charactershapes are some mixture of Song-, Ming- and > something resembling Kai-ti - But at least you can print in a > good resolution. That sounds wonderful! Please let me know if you manage to generate a 64x64 Big5 font. I could use it in future versions of my Flash program. It would also be good for printer software such as Poor Man's Chinese TeX, and HBF-based software such as hz2ps. -- Steve Simpson Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20 AT PSUVM FAX: +1 814 865-3735 From CAI@neurophys.wisc.edu Mon Aug 30 13:46:36 1993 Return-Path: Date: Mon, 30 Aug 93 13:41 CST From: CAI@neurophys.wisc.edu Subject: HBF files To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: RO From: IN%"xiaofei@ifcss.ORG" 28-AUG-1993 16:07:20.47 These files have been posted by Y. D. Cai using different filenames: ccfs24.hbf cclib.n24 cch24.hbf cclib.h24 cck24.hbf cclib.k24 ccs24.hbf cclib.j24 ccs24f.hbf cclib.f24 ------- I trust FF Lee's work. I think Xiaofei can delete those ones originally posted by me. Also, I hope Lee could spend some time to modify/rewrite the README file for /software/fonts/HBF directory to elimilate the existing inconsistancies. Yidao Cai From simpson@math.psu.edu Mon Aug 30 20:40:00 1993 Return-Path: From: Stephen G Simpson Date: Mon, 30 Aug 93 21:36:14 -0400 To: soft-authors@ifcss.org Subject: extending HBF to 3 and 4 byte coding systems Status: RO Recently there has been some discussion on CCNET about CCCII, a code system for Chinese characters that includes 75,684 characters, including both fantizi and jiantizi and many variant forms. It is used in scholarly work involving classical texts etc. It is a de facto standard in library science. The following question was raised by Christian Wittern : > I'm not very familiar with HBF, but would it be possible to extend > it so as to accomodate 3 or 4 byte codes like CCCII? I'd love to > see something like cccii2ps :-) Any thoughts on this? Also, I believe there is something called EUC (extended Unix code) which is a 3 or 4 byte coding system. What about extending HBF to EUC fonts? -- Steve Simpson From lee@simd.Stanford.EDU Wed Sep 1 02:22:30 1993 Return-Path: Date: Wed, 1 Sep 93 00:18:19 -0700 From: lee@simd.stanford.edu (Fung Fung Lee) To: simpson@math.psu.edu Cc: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Mon, 30 Aug 93 21:36:14 -0400 <9308310136.AA09310@boole.math.psu.edu> Subject: extending HBF to 3 and 4 byte coding systems Status: RO >From: Stephen G Simpson >Date: Mon, 30 Aug 93 21:36:14 -0400 > >Recently there has been some discussion on CCNET about CCCII, a code >system for Chinese characters that includes 75,684 characters, >including both fantizi and jiantizi and many variant forms. It is >used in scholarly work involving classical texts etc. It is a de >facto standard in library science. As long as there is a fixed valid code range for each byte, ==================================== it should be easy to handle any hanzi code in HBF 1.0 or HBF 1.x, right? In fact, M.C. Pong has anticipated future extension, and that's why we have something like HBF_BYTE_2_RANGE. Similarly, we can have HBF_BYTE_4_RANGE, etc. So, can CCCII be handled this way? Fung From rap@doc.ic.ac.uk Mon Sep 6 04:49:26 1993 Return-Path: Date: Mon, 6 Sep 93 10:46 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: extending HBF to 3 and 4 byte coding systems Cc: simpson@math.psu.edu Status: RO Stephen G Simpson wrote: > [...] > Also, I believe there is something called EUC (extended Unix code) > which is a 3 or 4 byte coding system. What about extending HBF to > EUC fonts? My understanding is that EUC is a scheme for mixing text from up to 4 character sets, using the following byte sequences: set 0 00-7f ASCII (narrow) set 1 GR GR wide characters set 2 8e GR extra narrow set set 3 8f GR GR extra wide set Here GR (Graphic Right) means the range a1-fe. The wide sets are two-byte codes using the ranges 21-7e, like GB, JIS or KSC. The narrow set is a one-byte code. For example, the X locale zh_CN.ugb has GB as set 1 and the pinyin row of GB as set 2. The zh_TW.big5 locale has the two CNS sets as sets 1 and 3. Japanese locales have JIS-208 in set 1, JIS-201 (katakana) in set 2, and JIS-212 in set 3. So I think EUC is best treated as accessing a set of fonts, each using HBF files which probably already exist. It's up to the application program to process the EUC text. -- Ross Paterson Department of Computing, Imperial College, London SW7 From simpson@math.psu.edu Tue Sep 7 11:06:56 1993 Return-Path: From: Stephen G Simpson Date: Tue, 7 Sep 93 11:58:56 -0400 To: soft-authors@ifcss.org Status: O Ross Paterson writes: > My understanding is that EUC is a scheme for mixing text from up to > 4 character sets, using the following byte sequences: > > set 0 00-7f ASCII (narrow) > set 1 GR GR wide characters > set 2 8e GR extra narrow set > set 3 8f GR GR extra wide set > > Here GR (Graphic Right) means the range a1-fe. The wide sets are two-byte > codes using the ranges 21-7e, like GB, JIS or KSC. The narrow set is a > one-byte code. For example, the X locale zh_CN.ugb has GB as set 1 and > the pinyin row of GB as set 2. The zh_TW.big5 locale has the two CNS > sets as sets 1 and 3. Japanese locales have JIS-208 in set 1, JIS-201 > (katakana) in set 2, and JIS-212 in set 3. > > So I think EUC is best treated as accessing a set of fonts, each using > HBF files which probably already exist. It's up to the application > program to process the EUC text. Ross, thanks for the concise explanation. You know, I read some articles about EUC but it didn't explain it this well. I'm sure you're right -- there is no need to extend HBF to take account of EUC. -- Steve From simpson@math.psu.edu Tue Sep 7 12:09:54 1993 Return-Path: From: Stephen G Simpson Date: Tue, 7 Sep 93 13:06:03 -0400 To: soft-authors@ifcss.org Cc: handa@etl.go.jp Subject: some ideas about extending HZ to Big5 Status: O To: Chinese software authors discussion list Concerning possible extensions of the HZ standard to cover Big5, I guess you remember that we had a little discussion about this some time ago. In the meantime I have been looking at Mule, a multilingual extension of GNU Emacs developed by Ken'ichi Handa and some other people in Japan. The Mule-junet file format is interesting because it allows you to mix multiple character sets such as ASCII, GB, Big5, JIS, KSC, ISO-Latin1, etc. etc. using escape sequences to switch from one character set to another. Furthermore, Mule-junet files are 7-bit files and can be sent everywhere by e-mail. In addition to standard printable ASCII, the only other character that appears in Mule is the Escape character, 0xB1. Some of the escape sequences used in Mule-junet are: Escape $ ( A switch to GB2312 Escape $ ( 0 switch to Big5 level 1 Escape $ ( 1 switch to Big5 level 2 Escape , A switch to ISO-Latin1 Escape ( B switch to ASCII Big5 levels 1 and 2 are packed into the 0x21-0x7E 0x21-0x7E range, in order, using the B2G macro in mule/src/codeconv.h. So far as I can tell, the Mule-junet file format is peculiar to Mule, i.e. it is not supported by other software. However, it is an extension of the format used in Japanese e-mail, and it is closely related to international standards such as ISO 2022 and EUC. (But I don't understand these standards very well.) It is interesting to note that HZ is already in a sense compatible with Mule-junet, the only big difference being the use of ~{ and ~} instead of ESC $ ( A and ESC ( B. So, perhaps we should consider extending HZ in a way that retains this kind of compatibility with Mule-junet and related international standards. Any thoughts on how to do this? I mentioned this matter to Ken'ichi Handa and he came up with the following: > I also once considered the way to extend HZ for > multilingual. My idea was to put (final character such > as 'A' for GB, 'B' for JIS) just after ~ to make it > compatible with the current HZ. So, > GB -- ~A{ or ~{ > JIS -- ~B{ > KSC -- ~C{ > BIG5-1 -- ~0{ > BIG5-2 -- ~1{ > ASCII -- ~} (no change) > But this method is limited to such character sets that > never use the sequence ~}. Laint-1 can't be used with this > way of extension. Any thoughts on how to solve this problem? -- Steve Simpson Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20 AT PSUVM FAX: +1 814 865-3735 From simpson@math.psu.edu Mon Sep 20 13:12:27 1993 Return-Path: From: Stephen G Simpson Date: Mon, 20 Sep 1993 13:08:20 -0400 To: soft-authors@ifcss.org Subject: HBF files for KC fonts Status: O I have a question about kcm14.hbf. Namely, what the heck is going on here? > ... > HBF_CODE_RANGE 0xA15E-0xA15E kcchin16.f00 1220 > HBF_CODE_RANGE 0xA15F-0xA15F kcchin16.f00 1252 > COMMENT Too many to be adjusted. Getting lazy here. ANOTHER TOPIC: I would like to propose adding some segments to the kc*.hbf files in order to make them more compatible with the behavior of the KC and ET operating environments. Here is part of my modified kcm24.hbf. This is not perfect, but it gives access to Japanese and Russian alphabets, among other things. Comments and suggestions would be appreciated. CHARS 13875 HBF_START_BYTE_2_RANGES 2 HBF_BYTE_2_RANGE 0x40-0x7E HBF_BYTE_2_RANGE 0xA1-0xFE HBF_END_BYTE_2_RANGES COMMENT HBF_START_CODE_RANGES 12 HBF_CODE_RANGE 0xA140-0xA3BF kcchin24.f00 256 COMMENT punctuation marks, miscellaneous symbols, Arabic and Roman numerals, COMMENT Roman Greek and Bopomofo alphabets (308 characters). HBF_CODE_RANGE 0xA3C0-0xA3E0 kcchin24.f00 34168 COMMENT more miscellaneous symbols (33 characters). HBF_CODE_RANGE 0xA440-0xC67E kcchin24.f00 55336 COMMENT Big-5 level 1 (5401 characters). HBF_CODE_RANGE 0xC6A1-0xC6BE kcchin24.f00 29848 COMMENT miscellaneous numerals (30 characters). HBF_CODE_RANGE 0xC6D8-0xC6E3 kcchin24.f00 36688 COMMENT miscellaneous (12 characters). HBF_CODE_RANGE 0xC6E4-0xC6E6 kcchin24.f00 37696 COMMENT miscellaneous (3 characters). HBF_CODE_RANGE 0xC6E7-0xC876 kcchin24.f00 38056 COMMENT Japanese and Russian alphabets (236 characters). HBF_CODE_RANGE 0xC877-0xC878 kcchin24.f00 55192 COMMENT miscellaneous (2 characters). HBF_CODE_RANGE 0xC879-0xC8D3 kcchin24.f00 995296 COMMENT miscellaneous symbols (57 characters). HBF_CODE_RANGE 0xC940-0xF9D5 kcchin24.f00 444208 COMMENT Big-5 level 2 (7652 characters). HBF_CODE_RANGE 0xF9D6-0xF9D6 kcchin24.f00 29632 COMMENT miscellaneous (1 character). HBF_CODE_RANGE 0xF9D7-0xF9FE kcchin24.f00 999400 COMMENT miscellaneous characters and graphic symbols (40 characters). HBF_END_CODE_RANGES HBF_END_FONT -- Steve Simpson From simpson@math.psu.edu Mon Sep 20 23:38:29 1993 Return-Path: From: Stephen G Simpson Date: Tue, 21 Sep 1993 00:35:50 -0400 To: Ross Paterson Cc: soft-authors@ifcss.org Subject: HBF under MSDOS Status: O Hi Ross, I finally got around to trying out your hbf.c on my PC clone. I am using the version in /ifcss.org:/software/fonts/d/hbf-ross2.tar.Z. I found that it works under Turbo C 2.0 with only a few small changes. (I only did a quick test using tester. The command to compile tester was "tcc -Dmsdos tester hbf".) Next I think I'll try using your hbf.c in my Flash program. I'll let you know if I run into any problems. Best regards, Steve Simpson PS Here are the diffs for hbf.c. Maybe you want to make the "rb" flag be conditional on msdos, because Unix fopen probably won't recognize it. 11c11 < #include --- > /* #include */ 339c339 < #define HasDrive(fn) (isletter((fn)[0]) && (fn)[1] == ':') --- > #define HasDrive(fn) (isalpha((fn)[0]) && (fn)[1] == ':') 705c705 < (bmf->bmf_file = fopen(bmf->bmf_name, "r")) == NULL) --- > (bmf->bmf_file = fopen(bmf->bmf_name, "rb")) == NULL) From khsc@synoptics.com Tue Sep 21 11:44:28 1993 Return-Path: Date: Tue, 21 Sep 93 09:40:11 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: update to GB standard Status: RO Hello everybody, I have been looking a some of my books, one of them is the update to the GB chinese character coding scheme, it was published by GB in 1986, (sorry, I forgot the publication number, but I can post it if anyone is interested) basicly it defines the 32 bit font for the 8000 or so GB characters, at the same time, updates the orginal GB scheme by deinfining 5 additional characters between A8BB and A8BF, also, it defines the 10th qu (AA01 - AAFE) to be identical to the 3rd qu (ASCII order) except the bitmap font is half the width of the 3rd qu. Does anybody has a bitmap file for these font? |\/\/\/| =============================== | | ==================================== | | (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 mcpong@cs.ust.hk Wed Sep 22 01:13:39 1993 Return-Path: Date: Wed, 22 Sep 93 14:09:01 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) In-Reply-To: Simon Chow "HBF API" (Sep 22, 0:32) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Simon Chow Subject: Re: HBF API Cc: soft-authors@ifcss.org Status: O "Simon Chow " wrote on 1993 Sep 22 (Wed): > Ross, > > I have just started to look at the HBF api, apperently, there > are three API package on ifcss.org: > 1) /ifcss.org:/software/fonts/d/hbf-ross1.tar.Z > > 2) /ifcss.org:/software/fonts/d/hbf-ross2.tar.Z > /ifcss.org:/software/fonts/d/hbf-ross2-patch > > 3) /ifcss.org:/software/fonts/HBF/unix-c/hbf.tar.Z > > can you or somebody clearify the difference between these > packages? I have briefly looked at 2) and 3). I suggest that you can use (2). (3) was based on (1), but should be withdrawn now. If no objection from soft-authors@ifcss.org, I'll mail ftp-admin@ifcss.org to recommend the deletion of that file. mcpong@uxmail.ust.hk From simpson@math.psu.edu Wed Sep 22 02:18:56 1993 Return-Path: From: Stephen G Simpson Date: Wed, 22 Sep 1993 03:14:55 -0400 To: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Cc: soft-authors@ifcss.org In-Reply-To: <9309220609.AA04833@cs.ust.hk> Subject: Re: HBF API Status: O I agree that hbf-ross2 is the best version currently available at ifcss.org. But subsequently Ross made a few improvements. I suggest that Ross should upload his latest version, and all the other versions should be removed. Also, I think the latest version should be kept in ifcss.org:/software/fonts/HBF, not ifcss.org:/software/fonts/d. By the way, Ross's code now works not only under Unix but also under MS-DOS (I have tested it with Turbo C 2.0). -- Steve Simpson From CAI@neurophys.wisc.edu Mon Sep 27 10:29:59 1993 Return-Path: Date: Mon, 27 Sep 93 10:23 CST From: CAI@neurophys.wisc.edu Subject: HBF environment variable To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O Hi, Everybody: While more and more softwares are supporting HBF, it seems that different softwares used different environmental variable for the HBF font directory. For example, FFL's hzview used "HZFONTDIR", while I used "HBF" as proposed by Yagui earlier in our discussion, others may have used something else. This discrepency obviously causes some inconvenience to users who happen to run more than one softwares (I already got complaints). Here I propose (or repeat Yagui's earlier proposal since I do not remember exactly): 1. use an environmental variable for the HBF directory, which stores the HBF files and the bitmap font files. 2. use the same name in all systems. (since "HBF" is used in API, it may not be a good idea to use it for the environmental variable. How about FFL's "HZFONTDIR" or simply "HBFDIR" ?) 3. examples for different systems: DOS: in autoexec.bat, define HZFONTDIR=C:\subdir_for_hbf_font\ UNIX: in .cshrc file, setenv HZFONTDIR "~/dir_for_hbf_font/" VMS: In login.com, define $HZFONTDIR :== "DISK:[main.subdir_for_hbf_font]" Regards, Yidao Cai From rap@doc.ic.ac.uk Mon Sep 27 11:55:44 1993 Return-Path: Date: Mon, 27 Sep 93 17:50 BST From: Ross Paterson To: soft-authors@ifcss.org, xiaofei@ifcss.org Subject: Re: HBF environment variable Status: O CAI@neurophys.wisc.edu: :1. use an environmental variable for the HBF directory, which stores the : HBF files and the bitmap font files. : :2. use the same name in all systems. (since "HBF" is used in API, it : may not be a good idea to use it for the environmental variable. : How about FFL's "HZFONTDIR" or simply "HBFDIR" ?) xiaofei@ifcss.org: > I think HBFDIR is more appropriate since what the > program looks for is really the HBF files. This ought to be implemented in the open routine, so it's always the same. Under Unix, the usual thing would be to have an HBFPATH variable, containing a colon-separated list of directories to search for the HBF file name (unless the file name started with a slash). What do other systems do? From CAI@neurophys.wisc.edu Mon Sep 27 13:08:25 1993 Return-Path: Date: Mon, 27 Sep 93 13:03 CST From: CAI@neurophys.wisc.edu Subject: Re: HBF environment variable To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O From: IN%"rap@doc.ic.ac.UK" "Ross Paterson" 27-SEP-1993 11:53:24.78 Under Unix, the usual thing would be to have an HBFPATH variable, containing a colon-separated list of directories to search for the HBF file name (unless the file name started with a slash). What do other systems do? ----- On VMS, it is seperated by a comma. I don't care if the variable name is HBFPATH or other as long as we use the same one. But do we really need more than one directories for the HBF files? From khsc@synoptics.com Mon Sep 27 13:18:11 1993 Return-Path: Date: Mon, 27 Sep 93 11:12:45 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: HBF environment variable Status: O I will go for HBFDIR and I second the proposal of using ':' and ';' as directory names seperator on UNIX and DOS respectively, any suggestion on VMS and other system? |\/\/\/| =============================== | | ==================================== | | (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 simpson@math.psu.edu Mon Sep 27 15:59:13 1993 Return-Path: From: Stephen G Simpson Date: Mon, 27 Sep 1993 16:56:21 -0400 To: soft-authors@ifcss.org Cc: Ross Paterson Subject: HBF interface Status: O I have placed some HBF material for ftp at math.psu.edu, /pub/simpson/chinese/hbf. This material is mostly a subset of what is already available at ifcss.org, /software/fonts/d and /software/fonts/HBF. I added one thing, a crude program hbftopk which converts HBF fonts to TeX PK fonts, for use in Poor Man's Chinese TeX -- see also math.psu.edu, /pub/simpson/chinese/pmc. I am using Ross Paterson's C interface to HBF. Actually Ross has two interfaces, #1 which he calls a ``lightweight'' C interface, and #2 which conforms to the HBF 1.0 standard API. I am using #1. Ross, why do you call #1 a ``lightweight'' interface? It seems it can do everything the other interface can do. Or do you mean lightweight in some technical sense having to do with lightweight processes, threads, etc.? Once again, I would strongly urge that Ross keep a recent copy of his HBF interface in ifcss.org, /software/fonts/HBF, prominently labeled so that people can always find the latest version easily. As for the HBFPATH environment variable, I endorse the proposal that we have seen, i.e. make it a list of directories, separated by colons in Unix, semicolons in DOS, and I don't know what in VMS. -- Steve Stephen G. Simpson Department of Mathematics, Pennsylvania State University 333 McAllister Building, University Park, State College, PA 16802 Office phone: +1 814 863-0775 Internet: simpson@math.psu.edu Home phone: +1 814 238-2274 Bitnet: T20 AT PSUVM FAX: +1 814 865-3735 From mcpong@cs.ust.hk Mon Sep 27 19:26:40 1993 Return-Path: Date: Tue, 28 Sep 93 08:24:08 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: Re: HBF environment variable Status: O CAI@neurophys.wisc.edu: :1. use an environmental variable for the HBF directory, which stores the : HBF files and the bitmap font files. : :2. use the same name in all systems. (since "HBF" is used in API, it : may not be a good idea to use it for the environmental variable. : How about FFL's "HZFONTDIR" or simply "HBFDIR" ?) xiaofei@ifcss.org: > I think HBFDIR is more appropriate since what the > program looks for is really the HBF files. ----- I like "HBFDIR" more. It states about the HBF files are. (The bitmap files are stated inside the HBF files & can be transparent to the programs.) The different O.S. convention of "delimiter" separated list of directory names (like ":" in Unix, ";" in DOS, etc.) makes the program using HBF more complicated, though doable. Probably it's a good idea to let HBFDIR refer to one directory only. (I won't argue for it to be mandatory -- the program can do the best to cater for all versions on different platforms.) mcpong@uxmail.ust.hk From simpson@math.psu.edu Mon Sep 27 19:59:05 1993 Return-Path: From: Stephen G Simpson Date: Mon, 27 Sep 1993 20:56:53 -0400 To: soft-authors@ifcss.org Subject: mail log? and HBFPATH Status: RO Are the contributions on this list still being archived? The mail logs in /software/fonts/d seem to only go up to June 25. I favor HBFPATH over HBFDIR, i.e. a list of directories rather than a single directory. The reason is similar to why we have lists of directories for executables (PATH), man pages (MANPATH), X window fonts, TeX input and font paths, etc. etc. All of these environment variables can describe a list of directories. This is convenient because, for example, we don't necessarily want to put all of our X fonts in one directory. Consider for instance a big multiuser site where we have the X distribution fonts plus special X font packages used by particular applications, particular groups of users, etc. It is best to keep these special font packages separate from the X distribution. This way, when we upgrade from one version of X windows to another, we don't need to move the special fonts from one place to another. OS upgrades and maintenance are easier. Consider what would happen for instance if the HBF standard were to be incorporated as part of MIT X11. We would probably want to use the HBF fonts that were included with X11 but supplement them with our own fonts, which would be stored in a separate directory. So, we need HBFPATH to be a list of directories rather than a single directory. Of course, if you happen to have all your HBF fonts in one directory, your HBFPATH variable simply names that directory. -- Steve Simpson From ygz@cs.purdue.edu Mon Sep 27 20:31:05 1993 Return-Path: To: soft-authors@ifcss.org Subject: HBFPATH vs HBFDIR Date: Mon, 27 Sep 1993 20:28:40 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O I also favor HBFPATH. Font sharing is the compelling reason. You can define HBFPATH in DOS like: HBFPATH=.;C:\HBF;C:\CCDOS;C:\ET;C:\KC;C:\ZWDOS that contains directories for all the .hbf and bitmap files. You cannot achieve this using HBFDIR alone. Embedding the bitmap filename in the .hbf header is not good for exchanging the .hbf files. The path search and delimiter issues should be handled by the API. --ygz From jiang Mon Sep 27 23:56:37 1993 Return-Path: Date: Mon, 27 Sep 93 23:55:44 CDT From: jiang (Yuan Jiang) To: soft-authors Subject: Re: HBF environment variable Status: O I think HBFDIR is better too. From rap@doc.ic.ac.uk Tue Sep 28 07:49:58 1993 Return-Path: Date: Tue, 28 Sep 93 13:44 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBFPATH vs HBFDIR Status: O ygz@cs.purdue.edu (Yongguang Zhang) writes: > I also favor HBFPATH. Font sharing is the compelling reason. > You can define HBFPATH in DOS like: > > HBFPATH=.;C:\HBF;C:\CCDOS;C:\ET;C:\KC;C:\ZWDOS > > that contains directories for all the .hbf and bitmap files. > You cannot achieve this using HBFDIR alone. > > Embedding the bitmap filename in the .hbf header is not > good for exchanging the .hbf files. > > The path search and delimiter issues should be handled by the API. I've updated my HBF implementation to use HBFPATH on Unix and MSDOS. It's in ifcss.org:/incoming. It seems to work under Unix; I'd be grateful if someone would test it on DOS. Some day I hope to update the relative file name feature and HBFPATH to work under VMS, but it's too daunting for today. Stephen G Simpson wrote: > I am using Ross Paterson's C interface to HBF. Actually Ross has two > interfaces, #1 which he calls a ``lightweight'' C interface, and #2 > which conforms to the HBF 1.0 standard API. I am using #1. Ross, why > do you call #1 a ``lightweight'' interface? It seems it can do > everything the other interface can do. Or do you mean lightweight in > some technical sense having to do with lightweight processes, threads, > etc.? No technical meaning. The interface described in the appendix of the HBF document allows better error reporting (not present in my implementation) but is more cumbersome to program to, in my opinion. The idea of having 2 interfaces was to provoke discussion leading to a new single interface. -- Ross Paterson Department of Computing, Imperial College, London SW7 From yadong@stokes.rtpnc.epa.gov Tue Sep 28 08:20:37 1993 Return-Path: Date: Tue, 28 Sep 93 09:18:07 -0400 From: Yadong Yang To: soft-authors@ifcss.org Subject: Re: HBF environment variable Status: O I think either HBFDIR or HBFPATH is ok. However, I prefer supporting the option that the HBF files could be in different directories and/or subdirectories. This will leave more room for future upgrading. I think TeX deals with font directories nicely. ----------------- Yadong Yang 919-541-3518. From lee@umunhum.Stanford.EDU Tue Sep 28 13:27:27 1993 Return-Path: Date: Tue, 28 Sep 1993 11:13:15 -0700 From: lee@umunhum.Stanford.EDU (Fung Fung Lee) To: soft-authors@ifcss.org Subject: HBFPATH environment variable and .hbf extension Status: O HBFPATH: ------- I also favor HBFPATH as the name of the environment variable, containing a list of directory names separated by ':' in Unix, ';' in DOS, and ',' in VMS, following the common convention. What happens if HBFPATH is undefined? (getenv("HBFPATH") == NULL) If HBFPATH is NOT defined or is set to NULL (HBFPATH = ""), the default path is the current directory. Agree? In Macintosh OS, there is no environment variable, but the file name separator is ':' instead of '/' in Unix. (MacHD:Hanzi:Fonts:etk24.hbf) Since one can't get the path name through getenv in MacOS, we need to some way to pass it anyway. Therefore, I favor the API NOT trying to make a getenv() call to figure out the HBF pathname by itself. (The application can call getenv() or figure what to do if it can't call getenv.) Instead we'll have a new API function: char *HBF_SetPath(char *hbfPath); The prototype of every other function in defined HBF API 1.0 remains unchanged. Of course, the semantics of HBF_OpenFont() changes as we expect as there is now a search path. .hbf: ---- Since everyone (that I know of) accepts ".hbf" (NOTE: always in lower case) (all .hbf files in ifcss.org software archive should use lower case names) as the file name extension, why not push it inside the API, as we have just pushed the search path inside the API? Currently, Ross' implementation requires you to pass the whole file name including the .hbf extension. What do you guys think? To have maximum portability across multiple OS platforms, it's better to put the raw bitmap files in the same directory as the .hbf files. Otherwise, the pathnames of the bitmap files have to be spelled out, which are system dependent. I saw Ross' message this morning about his update. The hbf.h file (interface) seems unchanged. Clearly, it can't be the same thing as I have just outlined above. - FFL P.S. ANSI-C's strtok() [ strtok(pathname, ":") ] and strncat() will make the implementation really easy. I tried it on my hzview 3.0 using the same old API library. I'd rather see the changes handled in API as outlined above though. Perhaps it's also time to re-think about better error report (code) returned from HBF_OpenFont(). Some users of hzview / hz2ps complained to me about "Can't open font" error, which is triggered by a failure of HBF_OpenFont(). It's rather difficult to tell what's wrong given that so many things can lead to such a failure. This reminds me of Cai's previous comments and clearly the inadequacies in current implementation. From lee@umunhum.Stanford.EDU Tue Sep 28 13:43:43 1993 Return-Path: Date: Tue, 28 Sep 1993 11:39:08 -0700 From: lee@umunhum.Stanford.EDU (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Why don't applications take advantage of HBF? Status: O Just as I was looking for Ross' hbf.tar.Z in ifcss.org:incoming, I found also there cview120.doc. For a hanzi viewer, why does it have to work with GB codes only? but not also with BIG5 codes or any other ad hoc extensions of both? especially and presumably in horizontal display mode (vs. vertical display mode)? With the availability of HBF, I think this is no longer justified. It's almost always better to have ONE version supporting GB/BIG5/... than to have two or more versions of essentially the same thing. X's BDF allowed one version of cxterm and xhzview to serve both GB and BIG5 users long time ago! Should ifcss.org ftp-administrator send a message about HBF to everyone who has submitted software to ifcss.org, and (automatically) to those who will submit in the future? This will ensure that they are INFORMED about HBF and may VOLUNTARILY adopt HBF. -FFL ====================================================================== cview120.doc CView for OS/2 Version 1.20 (C) Copyright Minghua Shan 1993. All rights reserved. About CView v1.20 ================= CView v1.20 is a 32 bit, multi-threaded OS/2 PM application which can be used to view GuoBiao coded Chinese. o CView can handle files of any size. o It uses either 24x24 or 16x16 Chinese font. o With Cview v1.20, you can open multiple windows to view several files concurrently. o It supports drag-and-drop operations. Opening files is as easy as dragging the file objects and dropping them onto a CView window. What's New ========== Version 1.20 has the following new features: 1. multiple windows. 2. drag-and-drop support. 3. option to use either 24x24 or 16x16 Chinese font. Files in This Package ===================== This package includes the following files: CVIEW.EXE - CView executable CVIEW.HLP - Help library README.1ST - readme file README.INF - readme file in INF format. Enter "view readme.inf" to read. README.GB - a short note in Chinese Requirements ============ CView v1.20 requires an IBM PC or compatible running OS/2 v2.0 or later. This release also REQUIRES the following files: ZIKU24.1 and ZIKU24.2 or CCLIB.16 depending on whether you choose to use 24x24 font or 16x16 font. ZIKU24.1 and ZIKU24.2 are 24x24 bitmap Chinese font files. CCLIB.16 is 16x16 bitmap Chinese font. If you don't already have them, they are available via ftp from ifcss.org in directory /software/fonts. Note: If you prefer traditional (FanTi) Chinese characters, you may replace the file CCLIB.16 with CCLIBF.16, but you need to rename CCLIBF.16 to CCLIB.16. CCLIBF.16 is 16x16 traditional Chinese bitmap font. It is available via ftp from ifcss.org in directory /software/fonts. For More Informatioin: ====================== Read the file "README.1ST" included in the package for more information. From khsc@synoptics.com Tue Sep 28 14:47:16 1993 Return-Path: Date: Tue, 28 Sep 93 12:31:06 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: HBFPATH environment variable and .hbf extension Status: O > lee@umunhum.Stanford.EDU wrote on Tue Sep 28 11:35:06 1993 > > I also favor HBFPATH as the name of the environment variable, > containing a list of directory names separated by ':' in Unix, > ';' in DOS, and ',' in VMS, following the common convention. > > What happens if HBFPATH is undefined? (getenv("HBFPATH") == NULL) > If HBFPATH is NOT defined or is set to NULL (HBFPATH = ""), the default path > is the current directory. Agree? > Agree > Since one can't get the path name through getenv in MacOS, we need to > some way to pass it anyway. Therefore, I favor the API NOT trying to > make a getenv() call to figure out the HBF pathname by itself. > (The application can call getenv() or figure what to do if it can't call > getenv.) > Instead we'll have a new API function: > char *HBF_SetPath(char *hbfPath); > Agree > To have maximum portability across multiple OS platforms, it's better to > put the raw bitmap files in the same directory as the .hbf files. > Otherwise, the pathnames of the bitmap files have to be spelled out, > which are system dependent. I have to disagree on this point, while puting the .hbf file in the same directory as the bitmap file maximize portability, not everyone/site can do this, suppose the bitmap file is on a CDROM or under some common area where the use has no control of and the administrator is reluctant to put ANY user file in the common directory, the use will be stuck. However this can be overcome by specifiying HBFPATH to look under user's home directory for HBF file and specifies the bitmap file within the HBF. I understand this is a little messy. but I think the flexiblity outweight the inconvience, at least we have given the user choice, not limitations. |\/\/\/| =============================== | | ==================================== | | (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 CAI@neurophys.wisc.edu Tue Sep 28 14:52:25 1993 Return-Path: Date: Tue, 28 Sep 93 14:39 CST From: CAI@neurophys.wisc.edu Subject: Comments on FFL's two postings To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O From: IN%"lee@umunhum.Stanford.EDU" 28-SEP-1993 13:41:37.94 Subj: Why don't applications take advantage of HBF? Should ifcss.org ftp-administrator send a message about HBF to everyone who has submitted software to ifcss.org, and (automatically) to those who will submit in the future? This will ensure that they are INFORMED about HBF and may VOLUNTARILY adopt HBF. ------ Yes, more work is needed to let software authors and potential authors to get familar with the existance of HBF and its benefits. BTW, I think we may need a small document for Ross's API. I find it take quite some time to figure what's going on there (I haven't figured it out completely, I am still using my own API which was written when the discussion was going on). To people with little knowledge about HBF and its history, it may take more time. A sample implement of the API may be helpful. From: IN%"lee@umunhum.Stanford.EDU" 28-SEP-1993 13:26:36.92 Subj: HBFPATH environment variable and .hbf extension Instead we'll have a new API function: char *HBF_SetPath(char *hbfPath); ------ agree. .hbf: Since everyone (that I know of) accepts ".hbf" (NOTE: always in lower case) (all .hbf files in ifcss.org software archive should use lower case names) as the file name extension, why not push it inside the API, as we have just pushed the search path inside the API? Currently, Ross' implementation requires you to pass the whole file name including the .hbf extension. What do you guys think? ------ I don't see much benefit, but obviously there is no harm if we adopt it. To have maximum portability across multiple OS platforms, it's better to put the raw bitmap files in the same directory as the .hbf files. Otherwise, the pathnames of the bitmap files have to be spelled out, which are system dependent. ------ More explicitly, put the raw bitmap files in the same directory as the CORRESPONDING .hbf files, since you allow several dirs for hbf files. ------ It seems that the balance leans towards HBFPATH. From lee@simd.Stanford.EDU Tue Sep 28 15:02:31 1993 Return-Path: Date: Tue, 28 Sep 1993 12:58:16 -0700 From: lee@simd.Stanford.EDU (Fung Fung Lee) To: soft-authors@ifcss.org Subject: Re: HBFPATH environment variable and .hbf extension Status: O >Simon Chow wrote on Tue, 28 Sep 93 12:31:06 PDT >I have to disagree on this point, while puting the .hbf file in the same >directory as the bitmap file maximize portability, not everyone/site can >do this, suppose the bitmap file is on a CDROM or under some common area >where the use has no control of and the administrator is reluctant to >put ANY user file in the common directory, the use will be stuck. However >this can be overcome by specifiying HBFPATH to look under user's home >directory for HBF file and specifies the bitmap file within the HBF. I >understand this is a little messy. but I think the flexiblity outweight >the inconvience, at least we have given the user choice, not limitations. Simon is right. In fact, Ross' current implementation does allow the bitmap files to be anywhere with respect to the .hbf files. Well, in some cases, we just have to let the user do their own customization of .hbf files obtained from archive sites. -FFL From simpson@math.psu.edu Tue Sep 28 15:03:19 1993 Return-Path: From: Stephen G Simpson Date: Tue, 28 Sep 1993 15:56:03 -0400 To: soft-authors@ifcss.org Subject: HBF API and implementation Status: O F. F. Lee writes: > What happens if HBFPATH is undefined? (getenv("HBFPATH") == NULL) > If HBFPATH is NOT defined or is set to NULL (HBFPATH = ""), the default path > is the current directory. Agree? I agree, and this is exactly what what Ross's new implementation does. HBFPATH defaults to the current directory, and HBF_FileOpen finds HBF files given by a pathname which is either relative to a directory in HBFPATH, or absolute. I just tested this for DOS, it works there as well as for Unix. I think this is a good way to do things. > In Macintosh OS, there is no environment variable, but the file name > separator is ':' instead of '/' in Unix. (MacHD:Hanzi:Fonts:etk24.hbf) > Since one can't get the path name through getenv in MacOS, we need to > some way to pass it anyway. Therefore, I favor the API NOT trying to > make a getenv() call to figure out the HBF pathname by itself. > (The application can call getenv() or figure what to do if it can't call > getenv.) The API should not make a call to getenv, but I can't see any reason why an *implementation* of the API should not do so (on systems that support getenv). It is very nice to standardize this, even if not all systems support it. And, even on a system supporting getenv, an application can always ignore HBFPATH if it wants to (by passing only absolute pathnames to HBF_FileOpen). > Instead we'll have a new API function: > char *HBF_SetPath(char *hbfPath); I can't see what sense this would make on systems that do not support pathnames. Therefore, it should not be part of the API. > Since everyone (that I know of) accepts ".hbf" (NOTE: always in lower case) > (all .hbf files in ifcss.org software archive should use lower case names) > as the file name extension, why not push it inside the API, as we have > just pushed the search path inside the API? Currently, Ross' > implementation requires you to pass the whole file name including the .hbf > extension. What do you guys think? I like Ross's implementation. It allows more flexibility. The HBF files can have any name, the name doesn't have to end with .hbf (though particular applications may require this). Also, some operating systems may not support filename extensions, dots in filename extensions, etc. But every operating system has a well defined notion of filename. So, in the interest of keeping the API independent of the OS, let's not build in .hbf. > To have maximum portability across multiple OS platforms, it's better to > put the raw bitmap files in the same directory as the .hbf files. > Otherwise, the pathnames of the bitmap files have to be spelled out, > which are system dependent. But I like the flexibility of allowing them to be in different directories on systems which allow this, such as DOS and Unix. -- Steve Simpson From CAI@neurophys.wisc.edu Tue Sep 28 16:00:39 1993 Return-Path: Date: Tue, 28 Sep 93 15:47 CST From: CAI@neurophys.wisc.edu Subject: Same DIR for hbf files and raw bitmap files ? To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O I think by default the hbf file and the corresponding raw bitmap files should be in the same directory. However, the user is free to make changes to the hbf file so that it may point to somewhere else. The API should, upon failure from the first try with HBFPATH + "filename", try to locate the raw bitmap file "filename" under the "current" directory. The "filename" may include full path to the raw bitmap file. The API may also examine the "filename" first to determine if it already included the path (is Ross using the second approach in the new API?). From xiaofei Tue Sep 28 17:30:21 1993 Return-Path: Date: Tue, 28 Sep 93 17:30:20 CDT From: xiaofei (XiaoFei Wang) To: lee@umunhum.Stanford.EDU, soft-authors Subject: Re: Why don't applications take advantage of HBF? Cc: ftp-admin Status: O :Should ifcss.org ftp-administrator send a message about HBF to everyone :who has submitted software to ifcss.org, and (automatically) to those who :will submit in the future? This will ensure that they are INFORMED about :HBF and may VOLUNTARILY adopt HBF. : A good suggestion indeed. When soft-authors was created, I contacted all people who have submitted a software to ifcss.org and people I know. When times goes by, some people dropped, new people joined in, and new authors who submitted software may not know about HBF. I am going to do two things: 1) mass mailing to all of the authors whose name appear in ifcss.org:/software/catalogue to inform them about HBF and soft-authors 2) edititing incoming/.message to include info about HBF and soft-authors. I have tried to collect author' email addresses in catalogue. I have two things in mind: 1) it is easy to update 2) it is easy to generate usable all-author list To do this, I make sure that there is no repeatation and author's email address appear on the same line of author field. For example, software: hz2ps ...... author : Fung F. Lee, email: lee@stanford.edu Other info. software: hzview ...... author : Fung F. Lee, search 'Fung F. Lee' So if FFL's email address changes, I only need to change one place. And to generate a all-author list, one simple needs to 'egrep author catalogue' and do some editing. Do you have ideas to better achieve this? I am thinking of simply put the name in the author field, and at the end, put a author's list alphabetically. This is easier to make sure this is no repeatation, and avoid the awkwardness of attaching the author's full info to one of the software ( may not be his primary ), and asking the reader to jump around the file. Comments welcome. From simpson@math.psu.edu Tue Sep 28 20:07:35 1993 Return-Path: From: Stephen G Simpson Date: Tue, 28 Sep 1993 21:05:04 -0400 To: lee@simd.Stanford.EDU (Fung Fung Lee) Cc: soft-authors@ifcss.org In-Reply-To: <9309282358.AA26102@simd.Stanford.EDU> Subject: Re: HBFPATH environment variable and .hbf extension Status: O F. F. Lee writes: > What systems do not support pathnames? Note that MacOS does. PC-DOS 1.0! :-) How about CP-M? (I'm not sure.) IBM VM/CMS. I am familiar with only a very small number of operating systems. But, I think I see your point. The point is that application programs should have a way to set the search path for HBF fonts. And this should be possible on any operating system that supports some kind of directory structure, even if it is only different disks, as on VM/CMS. Is that right? I guess this is sensible, but how would it work in practice? Would every DOS or Unix application program have to do something like HBF_SetPath(getenv("HBFPATH"))? I would prefer to have the DOS and Unix HBF API libraries automatically read HBFPATH from the environment (default to the current directory), but allow application programs to override this with a call to HBF_SetPath, if so desired. This seems to combine simplicity with flexibility. -- S. Simpson From simpson@math.psu.edu Tue Sep 28 20:32:03 1993 Return-Path: From: Stephen G Simpson Date: Tue, 28 Sep 1993 21:20:51 -0400 To: soft-authors@ifcss.org Status: O I said: > I would prefer to have the DOS and > Unix HBF API libraries automatically read HBFPATH from the environment > (default to the current directory), but allow application programs to > override this with a call to HBF_SetPath, if so desired. This seems > to combine simplicity with flexibility. Following up on this, the HBF document and API specification could say something like the following: The HBF_FileOpen function shall search for HBF header files in a reasonable set of locations. The meaning of "reasonable set of locations" depends on the underlying operating system. Under systems such as DOS and Unix, which support environment variables and the concept of a current directory, the "reasonable set of locations" could be specified in an environment variable HBFPATH or the current directory in case HBFPATH is not in the environment. On other systems, the "reasonable set of locations" may be specified differently. There shall be an API function HBF_SetPath which can be used to override the "reasonable set of locations" on all systems. -- Steve From rap@doc.ic.ac.uk Wed Sep 29 10:07:41 1993 Return-Path: Date: Wed, 29 Sep 93 15:59 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: Same DIR for hbf files and raw bitmap files ? Status: O > I think by default the hbf file and the corresponding raw bitmap files > should be in the same directory. However, the user is free to make > changes to the hbf file so that it may point to somewhere else. The API > should, upon failure from the first try with HBFPATH + "filename", try > to locate the raw bitmap file "filename" under the "current" directory. > The "filename" may include full path to the raw bitmap file. The API > may also examine the "filename" first to determine if it already > included the path (is Ross using the second approach in the new API?). Perhaps I should give an illustration of how my implementation works under Unix. (For anone unfamiliar with Unix, it has a heirarchical directory structure, with directories separated by slashes, and .. being the parent directory. A filename starting with a slash is the full address from the root; other filenames are relative to the current directory.) I have my HBF files in the directory /homes/rap/lib/fonts/hbf and my bitmap files in /homes/rap/lib/fonts/bitmaps. If I call the HBF open function with an HBF filename /homes/rap/lib/fonts/hbf/Beijing24.hbf and that HBF file contains lines like HBF_CODE_RANGE 0xA1A1-0xAFFE ../bitmaps/Beijing24.0 0 (here the filename doesn't start with a slash, so it's relative) then the routine looks for the bitmap file relative to the location of the HBF file. In fact it looks for a file called /homes/rap/lib/fonts/hbf/../bitmaps/Beijing24.0 which is the same thing as /homes/rap/lib/fonts/bitmaps/Beijing24.0 As a special case of this rule, if the bitmap filename in the HBF file had just been a plain file, it would be searched for in the same directory as the HBF file. If the bitmap filename had been an absolute one (i.e. started with a slash) then the HBF filename is ignored for this purpose. With the most recent change, I now have an environment variable HBFPATH=/homes/rap/lib/fonts/hbf:/homes/zhang/hbf:/homes/wang/hbf (actually I'm lying about the last two for the sake of example) and now I can just can the HBF open routine with the name Beijing24.hbf. Note that this will only look in the directories named (and in that order), not the current one, unless I include . (Unix for current directory) in the list. (An empty entry in the list also means the current directory.) If I supply an absolute filename, HBFPATH is not used. If HBFPATH is not defined, relative filenames are sought in the current directory. The implementation works much the same way under DOS. It could also do something similar under VMS, but the messy filenames there have deterred me for now. And yes, the implementation does call getenv(). lee@umunhum.Stanford.EDU (Fung Fung Lee) writes: > In Macintosh OS, there is no environment variable, but the file name > separator is ':' instead of '/' in Unix. (MacHD:Hanzi:Fonts:etk24.hbf) How about this: the application programmer writes getenv(): const char *getenv(const char *name) { if (strcmp(name, "HBFPATH") == 0) return "MacHD:Hanzi:Fonts,MacHD:Kanji:Fonts"; return NULL; } From CAI@neurophys.wisc.edu Wed Sep 29 12:42:09 1993 Return-Path: Date: Wed, 29 Sep 93 12:31 CST From: CAI@neurophys.wisc.edu Subject: vms directory structure To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O I wrote: > I think by default the hbf file and the corresponding raw bitmap files > should be in the same directory. However, the user is free to make > changes to the hbf file so that it may point to somewhere else. The API > should, upon failure from the first try with HBFPATH + "filename", try > to locate the raw bitmap file "filename" under the "current" directory. > The "filename" may include full path to the raw bitmap file. The API > may also examine the "filename" first to determine if it already > included the path (is Ross using the second approach in the new API?). On VMS, a filename takes the following general form: mvs::mvsd:[cai.gb.font]ccs24.hbf where "mvs" is the node name, "mvsd" the disk name. (In practice, almost nobody uses the node name except in some extreme cases. I used it only for copying files) If the filename is relative to the current directory (not the root), then it looks like (suppose we are under mvsd:[cai.gb]): [.fonts]ccs24.hbf The structure makes it a little bit more difficult to tell a plain filename from one with disk name and directory name. From: IN%"rap@doc.ic.ac.UK" "Ross Paterson" 29-SEP-1993 10:05:44.89 I have my HBF files in the directory /homes/rap/lib/fonts/hbf and my bitmap files in /homes/rap/lib/fonts/bitmaps. If I call the HBF open function with an HBF filename /homes/rap/lib/fonts/hbf/Beijing24.hbf and that HBF file contains lines like HBF_CODE_RANGE 0xA1A1-0xAFFE ../bitmaps/Beijing24.0 0 (here the filename doesn't start with a slash, so it's relative) then the routine looks for the bitmap file relative to the location of the HBF file. In fact it looks for a file called /homes/rap/lib/fonts/hbf/../bitmaps/Beijing24.0 which is the same thing as /homes/rap/lib/fonts/bitmaps/Beijing24.0 ----------------------- This doesn't hold for VMS. However, it would work if we store the hbf files and the bitmap files in mvs::mvsd:[cai.gb.hbf]ccs24.hbf and mvs::mvsd:[cai.gb.hbf.fonts]cclib.j24 respectively, put a line like HBF_CODE_RANGE 0xA1A1-0xAFFE [.fonts]cclib.j24 in ccs24.hbf and define HBFPATH as "mvs::mvsd:[cai.gb.hbf]". But we could not simple concatenate them, for it will be mvs::mvsd:[cai.gb.hbf][.fonts]cclib.j24 What we really want here is mvs::mvsd:[cai.gb.hbf.fonts]cclib.j24 One of the starting point of Ross is that he put HBF files and bitmap files in different directories, which is convenient for unix and dos, but seems not for vms. It seems to me that we need somewhat different approaches for different systems to fit the needs of different people. Yidao Cai From rap@doc.ic.ac.uk Wed Sep 29 13:09:47 1993 Return-Path: Date: Wed, 29 Sep 93 19:06 BST From: Ross Paterson To: CAI@neurophys.wisc.edu, soft-authors@ifcss.org Subject: Re: vms directory structure Status: O Yidao Cai wrote: > [...] > One of the starting point of Ross is that he put HBF files and bitmap > files in different directories, which is convenient for unix and dos, > but seems not for vms. It will certainly be a pain to code, but convenient to use. Translating my example literally, you would have HBF_CODE_RANGE 0xA1A1-0xAFFE [-.fonts]cclib.j24 in a file called mvs::mvsd:[cai.gb.hbf]ccs24.hbf, so the bitmap file name should be mvs::mvsd:[cai.gb.hbf.-.fonts]cclib.j24 which is (I think -- otherwise even messier, but still possible) equivalent to mvs::mvsd:[cai.gb.fonts]cclib.j24 Relative filenames start with "[." or "[-"; any other kind of filename is absolute. In the DOS version, if the bitmap filename lacks a drive, it takes it from the HBF filename, if that has one. In VMS, this should be done with both the device and the node name. From yawei Wed Sep 29 17:51:55 1993 Return-Path: Date: Wed, 29 Sep 93 17:41:40 CDT From: yawei (Ya-Gui Wei) To: rap@doc.ic.ac.uk, soft-authors Subject: Re: Same DIR for hbf files and raw bitmap files ? Status: RO I don't think HBF files should contain directory information. That would make the HBF files non-portable (for example, to VMS systems). Rather, directory information should be supplied seperately. In DOS and Unix, an environment variable with structure similars to the "path=" variable would be very useful.