From xiaofei Wed Sep 29 18:34:30 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA01408; Wed, 29 Sep 93 18:34:30 CDT Date: Wed, 29 Sep 93 18:34:30 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9309292334.AA01408@ifcss.org> To: soft-authors Subject: announcement: soft-authors auto achieved Status: RO With the help from Jiang, Yuan, soft-authors is auto achieved starting from this message. Messages to this list will be deposited to a file yymm.log, where yy is the year and mm is the month, in the directory of ifcss.org:/software/fonts/d From mcpong@cs.ust.hk Thu Sep 30 02:47:40 1993 Return-Path: Date: Thu, 30 Sep 93 15:43:22 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: No directory info in HBF_CODE_RANGE Status: O -- "yawei@ifcss.org (Ya-Gui Wei)" wrote on 1993 Sep 30 (Thu): > 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. I like this for portability of HBF files; that is: Directory information could be given in HBFPATH. The raw-bitmap-file name in a HBF_CODE_RANGE line in HBF file should only be pure filename (without directory delimiter, and without absolute path name). According to a VMS programmer, one can use system service call, $TRNLNM(), within program to evaluate the value of a logical symbol defined in the command interpreter ("shell"-equivalent) level. For systems which doesn't support pathnames declaration in an environment variable, probably providing an API call to set the pathnames, as suggested by F.F.Lee, is a viable solution. mcpong@uxmail.ust.hk From simpson@math.psu.edu Thu Sep 30 08:04:35 1993 Return-Path: From: Stephen G Simpson Date: Thu, 30 Sep 1993 09:00:53 -0400 To: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Cc: soft-authors@ifcss.org In-Reply-To: <9309300743.AA22009@cs.ust.hk> Subject: No directory info in HBF_CODE_RANGE Status: O > Directory information could be given in HBFPATH. > The raw-bitmap-file name in a HBF_CODE_RANGE line > in HBF file should only be pure filename (without > directory delimiter, and without absolute path name). I don't understand either the theory or the practice of this proposal. On the practical side, how would it work? Under DOS or Unix, would there be one path for header files and another for bitmap files? Or one path for both? If the latter, would the entire path be searched for each bitmap file, or only the portion of the path after the directory containing the header file? It seems too confusing. It is also wasteful, because if a directory contains only bitmaps there is no need to search it for header files, and vice versa. On the theoretical side, this proposal seems to violate the philosophy of HBF. I always felt that a key principle of HBF is that the HBF header file is a program's sole interface to the font. This implies that all relevant information about the font is in the header file, including where to find the actual bitmaps. This information is system dependent, but that's in the nature of things. You can't avoid it by restricting yourself to pure filenames. That's because different operating systems have different pure filename formats. When you transfer fonts from one operating system to another, it may well be necessary to rename the bitmap files (for instance change them to 8.3 for DOS). It is neither desirable nor necessary for HBF header files to be completely portable to all operating systems with no changes. We should certainly not enforce this in the HBF standard. I like the current implementation, because of its elegance and flexibility. Right now, I can simply edit an HBF header file to point to bitmap files in any directory. (I have tested this under DOS and Unix and it works fine. Presumably it would work under MacOS also.) Such editing is a normal step in the process of installing a new HBF font. (The editing step is unnecessary provided the bitmap files are being stored under their original names and in the same directory as the header file.) Once the installation is done, applications and users need never worry about the bitmap files. All they need to know is the location of the HBF header file. That is the beauty of the HBF interface. -- Steve Simpson From CAI@neurophys.wisc.edu Thu Sep 30 10:08:27 1993 Return-Path: Date: Thu, 30 Sep 93 10:00 CST From: CAI@neurophys.wisc.edu Subject: Re: No directory info in HBF_CODE_RANGE To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O From: IN%"simpson@math.psu.EDU" "Stephen G Simpson" 30-SEP-1993 08:02:09.89 > The raw-bitmap-file name in a HBF_CODE_RANGE line > in HBF file should only be pure filename (without > directory delimiter, and without absolute path name). I don't understand either the theory or the practice of this proposal. ----- I do. flexibility. Right now, I can simply edit an HBF header file to point to bitmap files in any directory. (I have tested this under DOS and Unix and it works fine. Presumably it would work under MacOS also.) ----- But if you are going to ask users of your program to do the editing job, you'll probably be in trouble. Most users I know of know little about computer, they are afriad to deal with it and they prefer to follow your simple 1, 2, 3 steps. Such editing is a normal step in the process of installing a new HBF *********** ----- It seems to me you are turning an easy-to-use HBF into a less convenient one. I would rather consider it something to be done only by some experienced users. See below. font. (The editing step is unnecessary provided the bitmap files are being stored under their original names and in the same directory as the header file.) Once the installation is done, applications and users need never worry about the bitmap files. All they need to know is the location of the HBF header file. That is the beauty of the HBF interface. -- Steve Simpson ------ As I stated before, I think in general, the hbf file and the corresponding bitmap file should be stored under the same directory, thus there is no need for the end users to edit the hbf files. The hbf files in public domain should NOT contain any directory informa- tion. But, users are free to (or have to in some cases, e.g. when it is impossible to put hbf file and the bitmap file in the same directory) include some directory information in his/her OWN copy of hbf file (there is no way you can forbid this). I consider this to be a side product of HBF. Yidao Cai From simpson@math.psu.edu Thu Sep 30 11:26:21 1993 Return-Path: From: Stephen G Simpson Date: Thu, 30 Sep 1993 12:21:07 -0400 To: CAI@neurophys.wisc.edu Cc: soft-authors@ifcss.org In-Reply-To: <23093009585964@neurophys.wisc.edu> Subject: Re: No directory info in HBF_CODE_RANGE Status: O On the subject of editing HBF header files to point to bitmap files in other directories. CAI@neurophys.wisc.edu writes: > ----- But if you are going to ask users of your program to do the editing > job, you'll probably be in trouble. Most users I know of know little > about computer, they are afriad to deal with it and they prefer > to follow your simple 1, 2, 3 steps. > > ------ As I stated before, I think in general, the hbf file and the > corresponding bitmap file should be stored under the same directory, > thus there is no need for the end users to edit the hbf files. The > hbf files in public domain should NOT contain any directory informa- > tion. But, users are free to (or have to in some cases, e.g. when it > is impossible to put hbf file and the bitmap file in the same > directory) include some directory information in his/her OWN copy of > hbf file (there is no way you can forbid this). I completely agree with this. The way I said it earlier was: Simpson > (The editing step is unnecessary provided the bitmap files Simpson > are being stored under their original names and in the same Simpson > directory as the header file.) CAI also writes: > I consider this to be a side product of HBF. I would put it this way: The fact that HBF header files can be edited to point to bitmap files in other directories is not a property of the HBF standard or of the HBF API specification. Rather, it is a useful feature of a particular implementation of the HBF API (in this case, Ross Paterson's implementation for Unix and DOS). This useful feature should be documented, along with other documentation describing the other features of that particular implementation. From khsc@synoptics.com Thu Sep 30 12:02:09 1993 Return-Path: Date: Thu, 30 Sep 93 09:56:38 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: No directory info in HBF_CODE_RANGE Status: O > From CAI@neurophys.wisc.edu Thu Sep 30 08:09:57 1993 > > From: IN%"simpson@math.psu.EDU" "Stephen G Simpson" 30-SEP-1993 08:02:09.89 > > The raw-bitmap-file name in a HBF_CODE_RANGE line > > in HBF file should only be pure filename (without > > directory delimiter, and without absolute path name). > > I don't understand either the theory or the practice of this proposal. > ----- I do. > > flexibility. Right now, I can simply edit an HBF header file to point > to bitmap files in any directory. (I have tested this under DOS and > Unix and it works fine. Presumably it would work under MacOS also.) Fine, if we adopt the convention of NOT including any path info in the HBF file itself when we publish any HBF file, and recomment the use to put the HBF and bitmap file in the same directory whenever possible. This would maximize flexibilty. If the user do not wish or unable to put the two file together, then he can edit the HBF file based on the his/her operating environment. I still favor the ability to specify pathname in HBF file. I do agree with Stephen, that use the HBFPATH for bitmap create unnecessary confusions; if multiple bitmap files with the same name exists in more than one directory specified in HBFPATH, which one should be used? the first on found or the fist one found IN or AFTER the directory where the HBF file was found? HBFPATH=/usr/fonts:/usr/simon/hbf:/usr/john/hbf say the following files exists /usr/fonts/cclib.24 /usr/john/cclib.24 /usr/simon/hbf/cclib.hbf with filename=cclib.24 should the API use /usr/fonts/cclib.24 or /usr/john/cclib.24 There is reason for going either way. I just don't like the idea of overloading environment variables. It is NOT a good idea. I don't want to seen a new environment variable (such as HZBITMAPPATH) to be created either, there will be no 1 to 1 mapping between HBF found in HBFPATH and bitmap found in HZBITMAPPATH. |\/\/\/| =============================== | | ==================================== | | (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 Thu Sep 30 12:19:26 1993 Return-Path: From: Stephen G Simpson Date: Thu, 30 Sep 1993 13:16:50 -0400 To: soft-authors@ifcss.org In-Reply-To: <9309301656.AA00875@taichi> Subject: Re: No directory info in HBF_CODE_RANGE Status: O Simon Chow writes: > Fine, if we adopt the convention of NOT including any path info in the > HBF file itself when we publish any HBF file, and recomment the use to > put the HBF and bitmap file in the same directory whenever possible. > This would maximize flexibilty. If the user do not wish or unable to > put the two file together, then he can edit the HBF file based on the > his/her operating environment. I still favor the ability to specify > pathname in HBF file. Right, that's what I had in mind. The ability to edit HBF header files to specify pathnames for bitmap files should be a documented feature, but probably only the most sophisticated users will want to take advantage of this feature. The typical user will simply place the bitmap files in the same directory with the header file, and in this case there should be no need to edit the header file. Ross's current implentation works exactly this way. -- S. Simpson From gchen@geohub.gcn.uoknor.edu Thu Sep 30 13:03:42 1993 Return-Path: Date: Thu, 30 Sep 1993 11:55:58 -0500 From: gchen@geohub.gcn.uoknor.edu (Gongquan Chen) To: soft-authors@ifcss.org Subject: Re: Directory information in HBF file or environmental variable X-Vms-To: IN%"soft-authors@ifcss.org" X-Vms-Cc: GCHEN Status: O Why should somebody make such big fuss about directory info regarding use of hbf files? Different systems have diff. conventions to specify the directories, so why should this kind info be put into the .hbf file in the first place? Second, whether to use an environment variable, or what variable name to use should be the programmer's responsiblity. Remember many users don't understand or use environmental variables themselves at all. HBF protocal is created for the sake of users, then why should we put anything like this on the user's responsibility again? I believe the only "logical and reasonable" solution should be that the programmer puts the dir. infor. in the setup/configuration file of the program. As a PC programmer, I seriously doubt that HBF will be welcomed by the majority of Chinese PC programmers. The reasons: 1. C is not the only languages that are popular for PC. Pascal, Basic, even Fortran have been observed in writing Chinese programs. Who is gonna write the API's for these languages? Many "new" programmers, hobbists simply can't write them own API, particularly in languages like BASIC, and FORTRAN. If HBF is made only for users, but not also for peoples who want to learn to how to write Chinese programs, HBF should be at least partly a failure. 2. Do we really need HBF? I don't see many PC programmers' positive response. The proliferation of redundant Chinese fonts is mainly due to that fact many of these 16x16 and 24x24 GB fonts were initially designed by the mainland Chinese government units when there was no de facto protection for intellectual properties. The font and file formats are known by most programmers. Are we going to see more 24x24 or even some 48x48 fonts that can be accessible to the public? I doubt. Today, most commercial Chinese softwares will either compress the fonts (24x24 or whatever, including the scalable fonts) or encrypt them. Will our programs be able to access them by using a .HBF file? On the BIG5 side, I don't know much about it. But at least we don't many fonts that can be accessed by the public. Also, different vendors use different coding in certain ranges. I think they mean that they don't want others to use their fonts. Has BIG5 a real been\\ "standard" like GB2312-1980[?]? 3. Many people who post their PC programs on the net for public access are from mainland China background. Of course, they are more familiar with GB fonts. Their programs will also be mainly dealing with GB coding. Should we tell them that their programs should also support BIG5 because there is a HBF standard? After all, what is the major coding scheme for the Chinese files on the net? My point is what kind of coding scheme or font that a program will use is purely the freedom of the programmer. Whether the programs will be used by many people will be determined by the users not by the few programmers. Good day! Chen, Gongquan From rap@doc.ic.ac.uk Thu Sep 30 13:48:47 1993 Return-Path: Date: Thu, 30 Sep 93 19:44 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: HBF and directory names Status: O I've placed yet another version of hbf.tar.Z in ifcss.org:/incoming. This one is supposed to provide HBFPATH and relative filenames for VMS. Perhaps someone (Cai Yidao?) would like to try it out. (I hope the Unix and DOS versions still work.) Ross From khsc@synoptics.com Thu Sep 30 19:24:13 1993 Return-Path: Received: from synoptics.com (pobox.synoptics.com) by ifcss.org (4.1/IFCSS-Mailer) id AA25837; Thu, 30 Sep 93 19:24:13 CDT Received: from taichi (taichi.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA17295; Thu, 30 Sep 93 17:21:22 PDT Received: by taichi (4.1/2.0N) id AA03789; Thu, 30 Sep 93 17:21:20 PDT Message-Id: <9310010021.AA03789@taichi> Date: Thu, 30 Sep 93 17:21:20 PDT From: Simon Chow To: soft-authors@ifcss.org Subject: Re: Directory information in HBF file or environmental variable Status: RO > From gchen@geohub.gcn.uoknor.edu Thu Sep 30 11:09:29 1993 > > I believe > the only "logical and reasonable" solution should be that the programmer > puts the dir. infor. in the setup/configuration file of the program. Find let the setup/configration program do configuration of the HBF files. After all, the config program also modification of autoexec.bat, config.sys, .login, .profile etc. doesn't it? > > As a PC programmer, I seriously doubt that HBF will be welcomed by the > majority of Chinese PC programmers. The reasons: > 1. C is not the only languages that are popular for PC. Pascal, Basic, even > Fortran have been observed in writing Chinese programs. Who is gonna > write the API's for these languages? Many "new" programmers, hobbists > simply can't write them own API, particularly in languages like BASIC, > and FORTRAN. If HBF is made only for users, but not also for peoples > who want to learn to how to write Chinese programs, HBF should be at > least partly a failure. The API is a reference implementation, even a C programmer can choose to implement his own API if he does not like the reference implementation. If you like it take advantage of it. There is no BASIC or PASCAL API for X-WINDOWS either, would you call X a failure? I think HBF provided the Chinese computing community something that has been missing for a long time and it serve it purpose well. For new (non-C) programmer, they relly don't need to writte a formal API implementation if they don't want to. Just write a simple paser! > fonts that can be accessible to the public? I doubt. Today, most commercial > Chinese softwares will either compress the fonts (24x24 or whatever, including > the scalable fonts) or encrypt them. Will our programs be able to access > them by using a .HBF file? On the BIG5 side, I don't know much about it. This is a general problem with a lot of company, they need to understand that the value of the software is not in the font. (unless they are in the business of publishing font.) Even then These company need to grow and realize that they need to have an open API or publish format of their font for their product to get popular. Just look at Addobe and MicroSoft, they publish their font specification and let other software to use it! > But at least we don't many fonts that can be accessed by the public. There are BIG5 24x24 font available from KuoChao, which is publicly available on the net. > 3. Many people who post their PC programs on the net for public access are > from mainland China background. Of course, they are more familiar with > GB fonts. Their programs will also be mainly dealing with GB coding. > Should we tell them that their programs should also support BIG5 because > there is a HBF standard? After all, what is the major coding scheme > for the Chinese files on the net? My point is what kind of coding > scheme or font that a program will use is purely the freedom of the > programmer. Whether the programs will be used by many people will be > determined by the users not by the few programmers. Take a look at ifcss.org:/software, there are utilities and applications (based on HBF and otherwise that allow user to choose between BIG5 and GB standard) |\/\/\/| =============================== | | ==================================== | | (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 xiaofei Thu Sep 30 22:36:10 1993 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA00126; Thu, 30 Sep 93 22:36:10 CDT Date: Thu, 30 Sep 93 22:36:10 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9310010336.AA00126@ifcss.org> To: soft-authors Subject: hbf-ross[3-4].tar.Z Status: O I have named the two recent hbf.tar.Z by ross as hbf-ross3.tar.Z and hbf-ross4.tar.Z and put them in fonts/d directory. It seems that they are still in discussion stage. I would be happy to place the final version on fonts/HBF/unix-c which is empty right now. I have edited the catalogue file in /software directory. The change is I simply put author's name in the author filed and at the end add a 'biographical entries'. Please take a look if you are interested and mail me your comments. From butta1@cs.bu.edu Thu Sep 30 23:04:18 1993 Return-Path: Received: from cs-mail.bu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA00643; Thu, 30 Sep 93 23:04:18 CDT Received: from CSA.BU.EDU by cs-mail.bu.edu (5.61+++/Spike-2.1) id AA28971; Fri, 1 Oct 93 00:02:55 -0400 From: butta1@cs.bu.edu (Nelson Chin) Received: by csa.bu.edu (5.61+++/Spike-2.1) id AA08607; Fri, 1 Oct 93 00:02:54 -0400 Date: Fri, 1 Oct 93 00:02:54 -0400 Message-Id: <9310010402.AA08607@csa.bu.edu> To: soft-authors@ifcss.org Status: O i got the cclib16.hbf and cclibf24.hbf from ifcss.org and compared them and found some differences, ie: % testhbf cclib16 8abd shows n' % testhbf cclib24f 8abd shows m' which one is correct? Nelson