From @ziggy.usf.edu:peng@sunflash.eng.usf.edu Wed Dec 1 23:06:30 1993 Return-Path: <@ziggy.usf.edu:peng@sunflash.eng.usf.edu> Received: from ziggy.usf.edu by ifcss.org (4.1/IFCSS-Mailer) id AA13819; Wed, 1 Dec 93 23:06:30 CST Received: from sunflash.eng.usf.edu by ziggy.usf.edu with SMTP (5.65/25-eef) id AA17405; Wed, 1 Dec 93 23:48:21 -0500 Received: by sunflash.eng.usf.edu (4.1/25-eef) id AA27743; Thu, 2 Dec 93 00:04:58 EST Date: Thu, 2 Dec 93 00:04:58 EST From: Fan Peng (EE) Message-Id: <9312020504.AA27743@sunflash.eng.usf.edu> To: soft-authors@ifcss.org Status: O Hi there, I am a little confused about the HBF standard. Is it intended to only describe the bitmap font files? If so, why does it contain a lot of scalable font characteristics? It seems to me that some fields are just assigned some values subjectively. I need to display font name in Chinese in pulldown menu and/or in list box. Do you think it's appropriate to add this field to the Standard? I would like to see more discussion on scalable fonts, which is necessary for any serious application. I don't think we can just simply follow the standards of PS or true type. We need something that exploits the nature of Chinese chars. I spent some time on this problem and tried to develop a method to display Chinese in graphic environment. I designed an algorithm but never got chance to implement it. I'm presenting this algorithm here and looking for your comments. The algorithm is simple. If we need to display a Chinese char, say "peng2" (friend), in a given bounding box at given position, we can recursively display "yue4"(moon) twice at different positions with different bounding boxes. "yue4" is considered as a basic ideogram. We can display it by calling some installable "driver" functions, which display single stroke based on Bezeir curve technique. Different "driver" functions provide different font styles. There are three major problems involved in this algorithm. 1. Develop a coding scheme to distinguish basic and non-basic ideograms. 2. Design a font file structure to store position information. 3. implement "driver" functions. We can use a set of quadratic Bezeir curves to describe a basic stroke. We can ensure smoothness (first derivative continuous) by choosing appropriate vertices. Any Suggestion? Please do not reply to this account. I have to "shoot a bullet and change a place".:-) ZHANG, Zheng BTW, cclib.k24 in software/fonts directory is corrupted. Does anyone have a clean version? From zhang Thu Dec 2 07:24:27 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA16660; Thu, 2 Dec 93 07:24:27 CST Date: Thu, 2 Dec 93 07:24:27 CST From: zhang (Yunfei Zhang) Message-Id: <9312021324.AA16660@ifcss.org> To: soft-authors@ifcss.org Subject: please take this address off your list Status: RO >From Mailer-Daemon Wed Dec 1 23:25:55 1993 Subject: Returned mail: Host unknown To: Postmaster ----- Transcript of session follows ----- 451 net hang reading from yalevm.ycc.yale.edu: Connection timed out during greeting wait with yalevm.ycc.yale.edu 421 Host flynn.chem.columbia.edu not found for mailer ddn. 550 lz@flynn.chem.columbia.edu... Host unknown 421 cunyvm.cuny.edu: Connection refused by cunyvm.cuny.edu, will keep trying for 3 days 421 utarlvm1.uta.edu: Connection refused by utarlvm1.uta.edu, will keep trying for 3 days ----- Message header follows ----- Return-Path: <@ziggy.usf.edu:peng@sunflash.eng.usf.edu> Received: from ziggy.usf.edu by ifcss.org (4.1/IFCSS-Mailer) id AA13819; Wed, 1 Dec 93 23:06:30 CST Received: from sunflash.eng.usf.edu by ziggy.usf.edu with SMTP (5.65/25-eef) id AA17405; Wed, 1 Dec 93 23:48:21 -0500 Received: by sunflash.eng.usf.edu (4.1/25-eef) id AA27743; Thu, 2 Dec 93 00:04:58 EST Date: Thu, 2 Dec 93 00:04:58 EST >From: Fan Peng (EE) Message-Id: <9312020504.AA27743@sunflash.eng.usf.edu> To: soft-authors@ifcss.org From mcpong@cs.ust.hk Thu Dec 2 19:14:33 1993 Return-Path: Received: from cssu2.cs.ust.hk by ifcss.org (4.1/IFCSS-Mailer) id AA26697; Thu, 2 Dec 93 19:14:33 CST Received: by cssu2.cs.ust.hk (4.1/SMI-4.1) id AA03184; Fri, 3 Dec 93 09:12:56 HKT Date: Fri, 3 Dec 93 09:12:56 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Message-Id: <9312030112.AA03184@cs.ust.hk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: soft-authors@ifcss.org Subject: Re: attributes in HBF file Status: RO > I am a little confused about the HBF standard. Is it intended to only > describe the bitmap font files? If so, why does it contain a lot of scalable > font characteristics? It seems to me that some fields are just assigned some > values subjectively. I think the main reason is that many properties are X window system related so that an HBF file can be converted automatically to an X BDF file, and then the bitmap font can be used in X. (There's a utility "hbf2bdf" released by Ross Paterson.) > I need to display font name in Chinese in pulldown menu and/or in list > box. Do you think it's appropriate to add this field to the Standard? This is reasonable; probably another property can be added in the future version (or put in ADD_STYLE_NAME property?). In v.1, the assumption is that an HBF file is in ASCII. > I would like to see more discussion on scalable fonts, which is necessary > for any serious application. I don't think we can just simply follow the standards > of PS or true type. We need something that exploits the nature of Chinese chars. That might be taken up in later version of HBF or another standard, say, HOF. If more ideas of how to do it are suggested, maybe this will raise much interest. > I spent some time on this problem and tried to develop a method to display > Chinese in graphic environment. I designed an algorithm but never got chance to > implement it. I'm presenting this algorithm here and looking for your comments. > > The algorithm is simple. If we need to display a Chinese char, say "peng2" > (friend), in a given bounding box at given position, we can recursively display > "yue4"(moon) twice at different positions with different bounding boxes. "yue4" > is considered as a basic ideogram. We can display it by calling some installable > "driver" functions, which display single stroke based on Bezeir curve technique. > Different "driver" functions provide different font styles. > > There are three major problems involved in this algorithm. > > 1. Develop a coding scheme to distinguish basic and non-basic ideograms. > 2. Design a font file structure to store position information. > 3. implement "driver" functions. We can use a set of quadratic Bezeir curves to > describe a basic stroke. We can ensure smoothness (first derivative continuous) > by choosing appropriate vertices. This idea is raised every now and then, say, in the mailing list CCNET-L. Need good engineering work to make it work. Another problem is how to make the composed glyph looks nice. Some research work in China (and Taiwan?) have tried using basic strokes in Bezeir curve representation. The composition of strokes and components should affect the curve parameters of each other in order to have good looking glyph. How to tune the parameters (automatically) is still an open problem. (I am not working on this problem. Just interested to know any applicable results.) > ZHANG, Zheng -- mcpong ~{ลำร๑ึฮ~} From Ricky.Yeung@Eng.Sun.COM Thu Dec 2 20:59:15 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA28066; Thu, 2 Dec 93 20:59:15 CST Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17538; Thu, 2 Dec 93 18:57:43 PST Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA20411; Thu, 2 Dec 93 18:56:46 PST Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA24272; Thu, 2 Dec 93 18:57:38 PST Date: Thu, 2 Dec 93 18:57:38 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9312030257.AA24272@hk.Eng.Sun.COM> To: peng@sunflash.eng.usf.edu Cc: soft-authors@ifcss.org, Ricky.Yeung@Eng.Sun.COM In-Reply-To: Fan Peng (EE)'s message of Thu, 2 Dec 93 00:04:58 EST <9312020504.AA27743@sunflash.eng.usf.edu> Subject: New property for Chinese name Status: O > I need to display font name in Chinese in pulldown menu and/or in list > box. Do you think it's appropriate to add this field to the Standard? How about a property for font name in Japanese, one for Korean, etc? No, I don't think it's appropriate to add the field for "font name in Chinese" or whatever character code. What I think we might do is to take away the "ASCII" word from the HBF spec, so that an HBF file is a text file that could contain 8-bit code. (I didn't realize that HBF v.1 has the ASCII restriction.) The "FONT" property should be the right place for the font name. In the meantime, I think you can do one of the following: 1. If your std I/O library can read in 8-bit string, put the GB/Big5 coded font name in the FONT property. The HBF library (done by Ross or Cao) will take care it automatically. Note that if I/O lib doesn't, even adding a new field won't help unless you encode it in ASCII. Then see option 2. 2. Encode the font name in HZ (pure ASCII) and again use the FONT property. 3. (Not recommended.) As a last resort, use the COMMENT property like the C++ pragma feature and do your OWN localization with a special HBF file reader. For example, if you need to specify the font name in many languages (I think the right way would be to have different sets of HBF files localized for different languages for a particular font. The localization shouldn't be limited to font name, but other properties as well, such as copyright information, comments etc.). -Ricky From rap@doc.ic.ac.uk Fri Dec 3 10:05:58 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA08499; Fri, 3 Dec 93 10:05:58 CST Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0p5czQ-00070QC; Fri, 3 Dec 93 16:04 GMT Message-Id: Date: Fri, 3 Dec 93 16:04 GMT From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: New property for Chinese name Status: O Ricky.Yeung@Eng.Sun.COM writes: > > I need to display font name in Chinese in pulldown menu and/or > > in list box. Do you think it's appropriate to add this field to > > the Standard? > > How about a property for font name in Japanese, one for Korean, etc? > No, I don't think it's appropriate to add the field for "font name in > Chinese" or whatever character code. What I think we might do is to > take away the "ASCII" word from the HBF spec, so that an HBF file is a > text file that could contain 8-bit code. (I didn't realize that HBF v.1 > has the ASCII restriction.) The "FONT" property should be the right > place for the font name. The restriction is necessary for compatability with BDF, at least on those fields used by BDF, including "FONT". In the meantime, my implementation isn't fussy about extra fields, so one could invent an extra field for private use, say HBF_FONTNAME, and put 8-bit text or whatever in it. Ross From @ziggy.usf.edu:peng@sunflash.eng.usf.edu Sat Dec 4 21:46:50 1993 Return-Path: <@ziggy.usf.edu:peng@sunflash.eng.usf.edu> Received: from ziggy.usf.edu by ifcss.org (4.1/IFCSS-Mailer) id AA04920; Sat, 4 Dec 93 21:46:50 CST Received: from sunflash.eng.usf.edu by ziggy.usf.edu with SMTP (5.65/25-eef) id AA28118; Sat, 4 Dec 93 22:28:22 -0500 Received: by sunflash.eng.usf.edu (4.1/25-eef) id AA24171; Sat, 4 Dec 93 22:45:17 EST Date: Sat, 4 Dec 93 22:45:17 EST From: Fan Peng (EE) Message-Id: <9312050345.AA24171@sunflash.eng.usf.edu> To: soft-authors@ifcss.org Status: O Ricky.Yeung@Eng.Sun.COM writes: > How about a property for font name in Japanese, one for Korean, etc? > No, I don't think it's appropriate to add the field for "font name in > Chinese" or whatever character code. What I think we might do is to > take away the "ASCII" word from the HBF spec, so that an HBF file is a > text file that could contain 8-bit code. (I didn't realize that HBF v.1 > has the ASCII restriction.) The "FONT" property should be the right > place for the font name. Why not? In my fontinfo.ini file, I use something like "B1B2/B3B4/..." to specify font name in Chinese. You can interpret it as GB, BIG5 or even Korean depending on file type. It does not have to be 8-bit code. I think Ross' API can accommodate this easily. mc pong writes: >I think the main reason is that many properties are X window system related >so that an HBF file can be converted automatically to an X BDF file, >and then the bitmap font can be used in X. >(There's a utility "hbf2bdf" released by Ross Paterson.) This makes me beleive that current standard is targeted on X. I will not have any problem if the name of this standard is "HBF for X". Otherwise, it's a little "unfair" to non-X guys. Anyway this is not a big issue. The main reason I'm hesitate to endorse this standard is I feel that it does not solve the problem of duplicate bitmap font files in user's directory. To some extent, it even encourages programmers to create variant font files from more standard ones like cclib.?dd. For softwares like BYX that developed several years ago, it's reasonable to have a variant due to performance. But I don't think it's a good practice today. I more favor to standardize the names of those "master" bitmap files and register them in a clearhouse. Those variant bitmap files should be phased out gradually (Instead of registering them with HBF files). Maybe I'm asking too much. ZHANG, Zheng From Ricky.Yeung@Eng.Sun.COM Sun Dec 5 18:20:01 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA15989; Sun, 5 Dec 93 18:20:01 CST Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24654; Sun, 5 Dec 93 16:18:29 PST Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29325; Sun, 5 Dec 93 16:17:27 PST Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA01460; Sun, 5 Dec 93 16:18:08 PST Date: Sun, 5 Dec 93 16:18:08 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9312060018.AA01460@hk.Eng.Sun.COM> To: peng@sunflash.eng.usf.edu Cc: soft-authors@ifcss.org In-Reply-To: Fan Peng (EE)'s message of Sat, 4 Dec 93 22:45:17 EST <9312050345.AA24171@sunflash.eng.usf.edu> Status: O > Ricky.Yeung@Eng.Sun.COM writes: > > How about a property for font name in Japanese, one for Korean, etc? > > No, I don't think it's appropriate to add the field for "font name in > > Chinese" or whatever character code. What I think we might do is to > > take away the "ASCII" word from the HBF spec, so that an HBF file is a > > text file that could contain 8-bit code. (I didn't realize that HBF v.1 > > has the ASCII restriction.) The "FONT" property should be the right > > place for the font name. > > Why not? In my fontinfo.ini file, I use something like "B1B2/B3B4/..." to > specify font name in Chinese. You can interpret it as GB, BIG5 or even Korean > depending on file type. It does not have to be 8-bit code. I think Ross' API > can accommodate this easily. I don't understand what you referring to with your "Why not?" Are you saying that we should add properties for font names in all languages? In the second half of my original message (which was deleted in your quote), I suggested the use of HZ code and DON'T need to use 8-bit code at all. In fact, I think using HZ code is better than the numeric code as suggested above, because then one may be able to view the Chinese characters easily. > mc pong writes: > >I think the main reason is that many properties are X window system related > >so that an HBF file can be converted automatically to an X BDF file, > >and then the bitmap font can be used in X. > >(There's a utility "hbf2bdf" released by Ross Paterson.) > > This makes me beleive that current standard is targeted on X. I will not have > any problem if the name of this standard is "HBF for X". Otherwise, it's a > little "unfair" to non-X guys. Anyway this is not a big issue. NO! HBF is NOT just for X. We chose HBF to be the super-set of BDF for its flexibility. Most of the BDF properties are optional in HBF. The required ones are basically needed no matter what you name them. We chose to name them the same as the BDF ones instead of inventing new names. > The main reason I'm hesitate to endorse this standard is I feel that it does > not solve the problem of duplicate bitmap font files in user's directory. To > some extent, it even encourages programmers to create variant font files from It does exactly the opposite. It does encourage and PROVIDE the mechanism to share BITMAP font files. It kinda encourages the creation of variant font DESCRIPTION files, which is ok, as HBF files are very small, comparing to the bitmap files. > more standard ones like cclib.?dd. For softwares like BYX that developed > several years ago, it's reasonable to have a variant due to performance. But The cclib (from CCDOS) proprietary bitmap format lacks the flexibilities and the proper mechanism to specify other important font properties. In my opinion, it's a lot worse than BDF, Windows' and Mac's Chinese font formats. > I don't think it's a good practice today. I more favor to standardize the names > of those "master" bitmap files and register them in a clearhouse. Those variant That means all the big companies would need to sit down and agree on one format. Unless the format is as flexible like BDF, the companies will need to spend a lot of money converting their existing applications. They can achieve sharing today by adapting something like HBF. The adaption should be easy and painless. > bitmap files should be phased out gradually (Instead of registering them with > HBF files). Maybe I'm asking too much. The variant BITMAP files will be OUT today if people endorse HBF! -Ricky From @ziggy.usf.edu:peng@sunflash.eng.usf.edu Mon Dec 6 22:03:09 1993 Return-Path: <@ziggy.usf.edu:peng@sunflash.eng.usf.edu> Received: from ziggy.usf.edu by ifcss.org (4.1/IFCSS-Mailer) id AA17274; Mon, 6 Dec 93 22:03:09 CST Received: from sunflash.eng.usf.edu by ziggy.usf.edu with SMTP (5.65/25-eef) id AA04365; Mon, 6 Dec 93 22:44:30 -0500 Received: by sunflash.eng.usf.edu (4.1/25-eef) id AA02755; Mon, 6 Dec 93 23:01:38 EST Date: Mon, 6 Dec 93 23:01:38 EST From: Fan Peng (EE) Message-Id: <9312070401.AA02755@sunflash.eng.usf.edu> To: soft-authors@ifcss.org Status: O > > > Why not? In my fontinfo.ini file, I use something like "B1B2/B3B4/..." to > > specify font name in Chinese. You can interpret it as GB, BIG5 or even Kor > > depending on file type. It does not have to be 8-bit code. I think Ross' A > > can accommodate this easily. >I don't understand what you referring to with your "Why not?" Are you >saying that we should add properties for font names in all languages? Let me clarify this. Fisrt, we are discussing Hanzi fonts here. We don't have to worry about the name in other languages. Second, if you insist that we are also dealing with other languages, it's fine. We can use this field to specify font name in a particular language, say, Japanese or Korean. Third, if you consider HZ code is better than the HEX form when you specify font name in Japanese or Korean, I don't have any objection. >NO! HBF is NOT just for X. We chose HBF to be the super-set of BDF for its >flexibility. Most of the BDF properties are optional in HBF. The >required ones are basically needed no matter what you name them. We >chose to name them the same as the BDF ones instead of inventing new >names. If that is the case, we should chose HBF to be the super-set of BDF, Windows and Mac's font formats. >It does exactly the opposite. It does encourage and PROVIDE the >mechanism to share BITMAP font files. It kinda encourages the creation >of variant font DESCRIPTION files, which is ok, as HBF files are very >small, comparing to the bitmap files. I didn't see the number of files in /software/fonts directory reduced. I don't think these files are totally independent. >That means all the big companies would need to sit down and agree on one >format. Unless the format is as flexible like BDF, the companies will >need to spend a lot of money converting their existing applications. >They can achieve sharing today by adapting something like HBF. The >adaption should be easy and painless. I never ask proprietary fonts to conform any standard. >The variant BITMAP files will be OUT today if people endorse HBF! If I endorsed HBF, I would give a HBF for bitmap file in my application. Another programmer also endorsed HBF, but he renamed the bitmap file and gave a different HBF. Users would end up with duplicate bitmap files. Applications seemed to share bitmap files, but what actually happened? ZHANG, Zheng From Ricky.Yeung@Eng.Sun.COM Tue Dec 7 12:58:36 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA26427; Tue, 7 Dec 93 12:58:36 CST Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15683; Tue, 7 Dec 93 10:55:51 PST Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21395; Tue, 7 Dec 93 10:54:44 PST Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA05877; Tue, 7 Dec 93 10:55:18 PST Date: Tue, 7 Dec 93 10:55:18 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9312071855.AA05877@hk.Eng.Sun.COM> To: peng@sunflash.eng.usf.edu Cc: soft-authors@ifcss.org In-Reply-To: Fan Peng (EE)'s message of Mon, 6 Dec 93 23:01:38 EST <9312070401.AA02755@sunflash.eng.usf.edu> Status: O > > > Why not? In my fontinfo.ini file, I use something like "B1B2/B3B4/..." to > > > specify font name in Chinese. You can interpret it as GB, BIG5 or even Kor > > > depending on file type. It does not have to be 8-bit code. I think Ross' A > > > can accommodate this easily. > > >I don't understand what you referring to with your "Why not?" Are you > >saying that we should add properties for font names in all languages? > > Let me clarify this. Fisrt, we are discussing Hanzi fonts here. We don't have > to worry about the name in other languages. Second, if you insist that we are We're talking about the Hanzi font name here. Many of the existing ones are named in English like Song, FongSong. Then why not in German, Japanese, or Korean (just the font name). > also dealing with other languages, it's fine. We can use this field to specify > font name in a particular language, say, Japanese or Korean. Third, if you > consider HZ code is better than the HEX form when you specify font name in > Japanese or Korean, I don't have any objection. > >NO! HBF is NOT just for X. We chose HBF to be the super-set of BDF for its > >flexibility. Most of the BDF properties are optional in HBF. The > >required ones are basically needed no matter what you name them. We > >chose to name them the same as the BDF ones instead of inventing new > >names. > > If that is the case, we should chose HBF to be the super-set of BDF, Windows > and Mac's font formats. The Windows and Mac's font formats are proprietary and lack the flexibility to share Han character fonts across incompatibale formats. I shouldn't say HBF is a "super-set" of BDF. It should be "We chose HBF to be very similar to BDF in syntax for its flexibility". > >That means all the big companies would need to sit down and agree on one > >format. Unless the format is as flexible like BDF, the companies will > >need to spend a lot of money converting their existing applications. > >They can achieve sharing today by adapting something like HBF. The > >adaption should be easy and painless. > > I never ask proprietary fonts to conform any standard. With HBF, the companies don't need to change their proprietary font formats! > >The variant BITMAP files will be OUT today if people endorse HBF! > If I endorsed HBF, I would give a HBF for bitmap file in my application. > Another programmer also endorsed HBF, but he renamed the bitmap file and gave > a different HBF. Users would end up with duplicate bitmap files. Applications > seemed to share bitmap files, but what actually happened? > > ZHANG, Zheng You don't rename the bitmap file, use an HBF file! [ ... cut and paste from above ...] > >It does exactly the opposite. It does encourage and PROVIDE the > >mechanism to share BITMAP font files. It kinda encourages the creation > >of variant font DESCRIPTION files, which is ok, as HBF files are very > >small, comparing to the bitmap files. > > I didn't see the number of files in /software/fonts directory reduced. > I don't think these files are totally independent. I think you're confused with the bitmap file and the HBF file (which is a small description text file). I recommend the article (in Chinese) written by Yidao Cao (posted to HXWZ and alt.chinese.text quite a while ago). If it's not available, could someone put it in the ifcss HBF archive? It's a good introduction to HBF, also an interesting reading. -Ricky From xiaofei Tue Dec 7 15:15:48 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA28960; Tue, 7 Dec 93 15:15:48 CST Date: Tue, 7 Dec 93 15:15:48 CST From: xiaofei (XiaoFei Wang) Message-Id: <9312072115.AA28960@ifcss.org> To: soft-authors@ifcss.org Subject: the HBF intro in chinese Cc: cnd-cm@cnd.org, yawei Status: RO Ricky mentioned the Yidao Cai's intro file for HBF. It is available from ifcss.org:/software/fonts/d. The filename is HBF.intro In a latter issue of HXWZ, a British reader commented that the font files used by ZWDOS and NJSTAR are exchangeable by twisting the zwdos configuration file, contrary as what was claimed in Cai's intro file. However this does not affect the opinions represented in Cai's article. In fact, the ZWDOS configuration file serves the same purpose as HBF file, so we can call it psudo-HBF file. The fact that the font files of ZWDOS ad NJSTAR can be exchanged is due to the this psudo-HBF file. So the finding of this british reader actually strengthens the arguments represented in Cai's article. ZWDOS is not alone in using the psudo-HBF file, another example is Chen Gongquuan's HXLASER software. So intead of the various psudo-HBF file by various authors, it is better to use the general, standardized real HBF file. I applaud for the efforts your guys have made in bringing this standard. It seems we still have a long way to go to have people accept this standard. From Ricky.Yeung@Eng.Sun.COM Tue Dec 7 15:41:16 1993 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA29474; Tue, 7 Dec 93 15:41:16 CST Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AB19316; Tue, 7 Dec 93 13:39:46 PST Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06667; Tue, 7 Dec 93 13:38:33 PST Received: by hk.Eng.Sun.COM (4.1/SMI-4.1) id AA06593; Tue, 7 Dec 93 13:39:05 PST Date: Tue, 7 Dec 93 13:39:05 PST From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9312072139.AA06593@hk.Eng.Sun.COM> To: xiaofei@ifcss.org Cc: soft-authors@ifcss.org In-Reply-To: XiaoFei Wang's message of Tue, 7 Dec 93 15:15:48 CST <9312072115.AA28960@ifcss.org> Subject: Re: the HBF intro in chinese Thanks, XiaoFei. Maybe you want to append your message to Yidao's article. BTW, starting tomorrow, I'll be off the net for about 40 days (I'll be in Hong Kong). -Ricky > Date: Tue, 7 Dec 93 15:15:48 CST > From: xiaofei@ifcss.org (XiaoFei Wang) > > Ricky mentioned the Yidao Cai's intro file for HBF. It is available > from ifcss.org:/software/fonts/d. The filename is HBF.intro > > In a latter issue of HXWZ, a British reader commented that the font > files used by ZWDOS and NJSTAR are exchangeable by twisting the zwdos > configuration file, contrary as what was claimed in Cai's intro file. > However this does not affect the opinions represented in Cai's article. > In fact, the ZWDOS configuration file serves the same purpose as HBF > file, so we can call it psudo-HBF file. The fact that the font files > of ZWDOS ad NJSTAR can be exchanged is due to the this psudo-HBF file. > So the finding of this british reader actually strengthens the > arguments represented in Cai's article. > > ZWDOS is not alone in using the psudo-HBF file, another example is Chen > Gongquuan's HXLASER software. So intead of the various psudo-HBF > file by various authors, it is better to use the general, standardized > real HBF file. I applaud for the efforts your guys have made in > bringing this standard. It seems we still have a long way to go to have > people accept this standard. From rap@doc.ic.ac.uk Thu Dec 9 06:13:59 1993 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA25604; Thu, 9 Dec 93 06:13:59 CST Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0p7kEF-00070RC; Thu, 9 Dec 93 12:12 GMT Message-Id: Date: Thu, 9 Dec 93 12:12 GMT From: Ross Paterson To: soft-authors@ifcss.org Subject: Notes on CJK codes I've placed my notes on CJK codes and encodings in ifcss.org:/software/info/cjk-codes.inf I'd be interested to hear of any errors or omissions. -- Ross Paterson From butta1@crsa.bu.edu Sun Dec 26 01:14:40 1993 Return-Path: Received: from crsa.bu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA07237; Sun, 26 Dec 93 01:14:40 CST Received: by crsa.bu.edu (5.61+++/Spike-2.1) id AA03109; Sun, 26 Dec 93 02:13:06 -0500 Date: Sun, 26 Dec 1993 02:13:04 -0500 (EST) From: C I I Project Sender: C I I Project Reply-To: C I I Project Subject: hku fonts and gb kaishu fonts To: Software Authors Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII can someone clarify what's the relationship among hku-ch16.*, chinese.16, chinese.16.new in ifcss.org:/software/fonts, i suppose they originated from a fontfile contributed from HKU.. and a bdf was also produced, and then remodified to be used in cxterm.. also, is chinese.16.new suppose to redefine chinese.16 to the correct big5 standard in the infrequent characters, eg like the ones in ETen fonts. also, if chinese.16 is the hku big5 font, then chinese16.hbf should have the X11R5 XLFD say big.hku instead of big5. also, i couldn't find the copyright notice of the fonts in the chinese.16.hbf, I think that the COPYRIGHT field in hbf files should also include copyright info about the bitmap fonts also, not just saying that "this hbf header file is placed in public domain". on a different note, has the hbf header file remedied any of the kaishu fonts on ifcss.org... if not how about an hbf header file for kai24.fon which claims to be complete. According to kai24fon.doc: Since all the Kaishu font files at ifcss.org (say cclibk.24, cclib.k24 and cclib.k24.ccf) are severely damaged and incomplete, (the output is dirty and more than 350 characters are absent, I make this Kaishu font availabe to the net This font KAI24.fnt is ONLY FREE FOR PERSONAL USE! For any other purpose or change the format please contact me for details under the address follows. Software developer, Software: softfont 24x24 bitmaped font in simplified format, Kaishu style. Filename: kai24fnt.zip, kai24fnt.doc Author : Xiangbo Kang This font is a byproduct of 48x48 bitmaped font kai48.fnt, which is almost ready to be released. Any suggestion is welcome. For details write to: xkang@dosuni1.bitnet Xiangbo Kang May 15th, 1993 Thanx for anyone who can shed some lite to my inquiries. Nelson Chin From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Tue Dec 28 06:42:38 1993 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT> Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by ifcss.org (4.1/IFCSS-Mailer) id AA17994; Tue, 28 Dec 93 06:42:38 CST Message-Id: <9312281242.AA17994@ifcss.org> Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 2093; Tue, 28 Dec 93 13:41:00 MEZ Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.1d/1.7f) with BSMTP id 7838; Tue, 28 Dec 1993 13:40:59 +0100 Date: Tue, 28 Dec 93 13:38:16 MEZ From: Werner Lemberg Subject: Search for most used Chinese characters To: soft-authors@ifcss.org, unicode@unicode.org I search a list of the most used Chinese characters and the most used Chinese words (both sorted by frequency). Where can I find such lists (if possible as files) ? Werner From butta1@bu.edu Wed Dec 29 19:30:47 1993 Return-Path: Received: from email-server.bu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA16994; Wed, 29 Dec 93 19:30:47 CST Received: from ACS.BU.EDU by email-server.bu.edu (5.61+++/Spike-2.1) id AA19468; Wed, 29 Dec 93 20:29:09 -0500 Date: Wed, 29 Dec 1993 20:26:58 -0500 (EST) From: Nihc Noslen Subject: taipei[k,m,l].bdf fonts To: Mark Leisher Cc: soft-authors@ifcss.org In-Reply-To: <9312292319.AA18927@NMSU.Edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Dec 1993, Mark Leisher wrote: > > where and what fontfiles did you make the BDFs of taipei[k,m,l].bdf > > from ? > > I generated these fonts from the original binary font files from the > ETEN package. We can't distribute the original fonts, so I had to > write a program to handle it. wouldn't the bdf files also be considered as copies of the originals, and thus still under ETen's copyright jurisdiction? is it equivalent to using the ETen hbf header files, like the ones on ifcss.org and binary fonts that comes with ETen system and then use hbftobdf and create bdf from there? btw, which version of eten are these fonts? nelson