From handa@etlken.etl.go.jp Fri Jul 1 00:29:04 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA26385; Fri, 1 Jul 94 00:29:04 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA10091; Fri, 1 Jul 94 14:22:06 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA12195; Fri, 1 Jul 94 14:22:05 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA07838; Fri, 1 Jul 94 14:22:12 JST Date: Fri, 1 Jul 94 14:22:12 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407010522.AA07838@etlken.etl.go.jp> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu In-Reply-To: Fung Fung Lee's message of Thu, 30 Jun 1994 20:12:54 -0700 <9407010312.AA15863@simd.stanford.edu> Subject: RE: A compromise proposal Status: O On Thu, 30 Jun 1994 20:12:54 -0700, lee@simd.stanford.edu (Fung Fung Lee) said: > Direct 7-bit BIG5 mapping refers to something like EHZ-BIG5, > HZ+, HZ-2, BETTY and almost every scheme proposed so far, > including HZ-EA-2, but NOT HZ-EA (or in Ricky's term, a convention > that proposes to use a restricted subset of EHZ). I still can't understand why you include HZ-EA-2 but not HZ-EA. Both map Big5-common to CNS (with re-ordering), user-defined to Private. The difference is only in vendor area. HZ-EA maps them to CNS/JIS(or GB)/Private but HZ-EA-2 maps to Private only. If this is the key point, I think you ment by "direct 7-bit BIG5 mapping" that "mapping method of Big5 should not differ amoung verious vendors". Correct? Then, I agree with you, that's one of the reason of my proposing HZ-EA-2. > Even if everything in EHZ is accepted, there is nothing to prevent > a user from choosing to follow Mr. Handa's suggestion to convert his/her > BIG5 text files to mixed CNS/GB/JIS EHZ files. Put it the other way, Ah! From your draft, I had got an impression that proposal of EHZ-BIG5 means Big5 should be mapped here. But, your real intention is to allow user (or programmer) to select what they want among EHZ-XXX (or even mixture of them) to encode whatever codes. Am I right? > EHZ-BIG5 simply allows him/her an alternative choice, which is more > straightforward, and is much much more likely to be supported by > more robust software because of the inherent simplicity of > BIG5<->EHZ-BIG5 translation vs. the first alternative. But, on this point of view, mapping method of HZ+S provides the simplest way. There must be some reason for your prefering EHZ-BIG5 to HZ+S. Could you explain it? > I am glad to see that Mr. Handa is spending effort to write some > conversion software based on the first approach. This is useful > just for the sake of 8-bit code translation. >>If both EHZ-CNS and EHZ-BIG5 are used, the process won't be >>facilitated, because there seems to be no reason for Big5 >>users to use EHZ-CNS instead of EHZ-BIG5. > You are probably right. If you are right, why not just support EHZ-BIG5 > and NO EHZ-CNS ? With only EHZ-BIG5, CNS can't be supported. > However, I'm not so sure you're right. Why not let the > USERS decide what they want to use, EHZ-BIG5 or EHZ-CNS? To allow users to decide them, we must, at first, provide both methods of Big5<->EHZ-BIG5 and Big5<->EHZ-CNS/EHZ-BIG5(plane0)[/EHZ-JIS]. Are you proposing that all softs which support EHZ must provide both of them and must provide a switch for users to select them? Then, soft writers load gets higher than supporting only HZ-EA[-2]. > Are you saying > that we should force upon the users one and only one alternative? Yes. We are already going to force upon the users only one way among EHZ, HZ+S, HZ-EA, ... >>I don't know the importance of difference of vendor parts >>being mapped to Plane1&2 or to Plane0. > That's why I mentioned it. You mean that the reason you choose Plane1&2 instead of Plane0 is that you want the possibility of Plane0 being used to be low? Why is it important provided that you support Plane0? In the case of HZ-EA-2, I must choose Private (or Plane0) area for vendor part because there's no other area. Private area can be used also for vendor part of GB and CNS if they exist. >>"Using common parts" is more promoted by HZ-EA-2 than by >>EHZ-BIG5 because HZ-EA-2 maps all non-common parts >>(vender/user area) to some Private code area. But, please >>note that such a promotion is not the reason of proposing >>HZ-EA[-2]. > Then what is the real reason? The reason is that I think it's better to map Big5 common part to CNS if we are going to support both Big5 and CNS. --- Ken'ichi HANDA handa@etl.go.jp From lee@simd.stanford.edu Fri Jul 1 15:33:32 1994 Return-Path: Received: from simd.stanford.edu by ifcss.org (4.1/IFCSS-Mailer) id AA28382; Fri, 1 Jul 94 15:33:32 CDT Received: by simd.stanford.edu (5.65/inc-1.0) id AA20425; Fri, 1 Jul 1994 13:30:48 -0700 Date: Fri, 1 Jul 1994 13:30:48 -0700 From: lee@simd.stanford.edu (Fung Fung Lee) Message-Id: <9407012030.AA20425@simd.stanford.edu> To: handa@etlken.etl.go.jp Cc: soft-authors@ifcss.org In-Reply-To: Kenichi Handa's message of Fri, 1 Jul 94 14:22:12 JST <9407010522.AA07838@etlken.etl.go.jp> Subject: A compromise proposal Status: O [[Happy July 4 long weekend vacation! I'll be gone for a few days. -FFL]] >Date: Fri, 1 Jul 94 14:22:12 JST >From: handa@etlken.etl.go.jp (Kenichi Handa) > >On Thu, 30 Jun 1994 20:12:54 -0700, >lee@simd.stanford.edu (Fung Fung Lee) said: >> Direct 7-bit BIG5 mapping refers to something like EHZ-BIG5, >> HZ+, HZ-2, BETTY and almost every scheme proposed so far, >> including HZ-EA-2, but NOT HZ-EA (or in Ricky's term, a convention >> that proposes to use a restricted subset of EHZ). >I still can't understand why you include HZ-EA-2 but not >>HZ-EA. Both map Big5-common to CNS (with re-ordering), >user-defined to Private. The difference is only in vendor >area. HZ-EA maps them to CNS/JIS(or GB)/Private but HZ-EA-2 >maps to Private only. If this is the key point, I think you >ment by "direct 7-bit BIG5 mapping" that "mapping method of >Big5 should not differ amoung verious vendors". Correct? >Then, I agree with you, that's one of the reason of my >proposing HZ-EA-2. Sorry. I misunderstood your HZ-EA[-2] proposals. The correction of my previous statement should be: Direct 7-bit BIG5 mapping refers to something like EHZ-BIG5, HZ+, HZ-2, BETTY and almost every scheme proposed so far, but NOT including HZ-EA, HZ-EA-2 (or in Ricky's term, a convention that proposes to use a restricted subset of EHZ). >> Even if everything in EHZ is accepted, there is nothing to prevent >> a user from choosing to follow Mr. Handa's suggestion to convert his/her >> BIG5 text files to mixed CNS/GB/JIS EHZ files. Put it the other way, >Ah! From your draft, I had got an impression that proposal >of EHZ-BIG5 means Big5 should be mapped here. But, your >real intention is to allow user (or programmer) to select >what they want among EHZ-XXX (or even mixture of them) to >encode whatever codes. Am I right? What can be done with EHZ should be clear from the examples from my spec. >> EHZ-BIG5 simply allows him/her an alternative choice, which is more >> straightforward, and is much much more likely to be supported by >> more robust software because of the inherent simplicity of >> BIG5<->EHZ-BIG5 translation vs. the first alternative. >But, on this point of view, mapping method of HZ+S provides >the simplest way. There must be some reason for your >prefering EHZ-BIG5 to HZ+S. Could you explain it? The rationale of my choice is the "anchoring principle" as explained in my spec. >> I am glad to see that Mr. Handa is spending effort to write some >> conversion software based on the first approach. This is useful >> just for the sake of 8-bit code translation. >>>If both EHZ-CNS and EHZ-BIG5 are used, the process won't be >>>facilitated, because there seems to be no reason for Big5 >>>users to use EHZ-CNS instead of EHZ-BIG5. >> You are probably right. If you are right, why not just support EHZ-BIG5 >> and NO EHZ-CNS ? >With only EHZ-BIG5, CNS can't be supported. Again, you are not quoting some of my statements in the previous message. I was just trying to follow your line of reasoning to expose some of its logical consequence, which is NOT desirable. >> However, I'm not so sure you're right. Why not let the >> USERS decide what they want to use, EHZ-BIG5 or EHZ-CNS? >To allow users to decide them, we must, at first, provide >both methods of Big5<->EHZ-BIG5 and >Big5<->EHZ-CNS/EHZ-BIG5(plane0)[/EHZ-JIS]. Are you >proposing that all softs which support EHZ must provide both >of them and must provide a switch for users to select them? >Then, soft writers load gets higher than supporting only >HZ-EA[-2]. I have never said anything about software implementation related to EHZ so far. All I have focused on is the EHZ specification. >> Are you saying >> that we should force upon the users one and only one alternative? >Yes. We are already going to force upon the users only one >way among EHZ, HZ+S, HZ-EA, ... Good, if that's your position. But that's not mine. >>>I don't know the importance of difference of vendor parts >>>being mapped to Plane1&2 or to Plane0. >> That's why I mentioned it. >You mean that the reason you choose Plane1&2 instead of >Plane0 is that you want the possibility of Plane0 being used >to be low? Why is it important provided that you support >Plane0? > >In the case of HZ-EA-2, I must choose Private (or Plane0) >area for vendor part because there's no other area. Private >area can be used also for vendor part of GB and CNS if they >exist. No one can prevent you or anyone else from trying it out for field testing. >>>"Using common parts" is more promoted by HZ-EA-2 than by >>>EHZ-BIG5 because HZ-EA-2 maps all non-common parts >>>(vender/user area) to some Private code area. But, please >>>note that such a promotion is not the reason of proposing >>>HZ-EA[-2]. >> Then what is the real reason? >The reason is that I think it's better to map Big5 common >part to CNS if we are going to support both Big5 and CNS. I see this as YOUR reason to promote HZ-EA (a MISNOMER by itself as you have previously confessed to Dr. Yeung's question), but I don't see it as the reason for HZ-EA-2. Fung Fung Lee From simpson@math.psu.edu Fri Jul 1 17:23:09 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA02986; Fri, 1 Jul 94 17:23:09 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id SAA17494; Fri, 1 Jul 1994 18:20:45 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 1 Jul 1994 18:20:43 -0400 Date: Fri, 1 Jul 1994 18:20:43 -0400 Message-Id: <199407012220.SAA14328@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: HZ+: something to think about In-Reply-To: <9407012030.AA20425@simd.stanford.edu> References: <9407010522.AA07838@etlken.etl.go.jp> <9407012030.AA20425@simd.stanford.edu> Reply-To: simpson@math.psu.edu Status: O I've been fairly quiet lately, and I'll probably be even more quiet over the Independence Day weekend. However, until my return, I'd like to leave everybody with something to think about. It seems to me that, in our discussions over 7-bit Chinese on the Internet, many people have been losing sight of the important distinction between the high road and the low road. The high road means a long-range approach based on official, multilingual standards such as Unicode and ISO-2022. The low road means pragmatic, temporary, quick-and-dirty solutions based on unofficial, popular standards such as HZ and Big5. Each road offers advantages and disadvantages. High road solutions will be better for the long run but harder to implement and slower to win wide acceptance. Low road solutions will be crude and impolite, but easy to implement and likely to win wide acceptance quickly. Nelson Chin and I advocate a combination of both methods -- the low road for the short term and the high road for the long term. It seems to me that many of the proposals that are now being discussed fall short because they are schizophrenic -- they can't decide whether to position themselves on the high road or the low road. An example is HZ-EA, which uses HZ-like escape sequences but excludes Big5. Another example is Doug Schiffer's proposal based on HZ and Unicode. Yet another example is EHZ, which offers infinite expansion possibilities can't decide between CNS (an unpopular high-road standard) and Big5 (a popular low-road standard). My own view is that there is urgent need for a thoroughly low-road solution which marries HZ and Big5 in the simplest possible way. This is the idea behind HZ+. At the same time, I applaud any and all efforts to promote high-road solutions such as ISO-2022 and Unicode. -- Steve From lee@simd.stanford.edu Fri Jul 1 21:16:08 1994 Return-Path: Received: from simd.stanford.edu by ifcss.org (4.1/IFCSS-Mailer) id AA09551; Fri, 1 Jul 94 21:16:08 CDT Received: by simd.stanford.edu (5.65/inc-1.0) id AA21955; Fri, 1 Jul 1994 19:13:50 -0700 Date: Fri, 1 Jul 1994 19:13:50 -0700 From: lee@simd.stanford.edu (Fung Fung Lee) Message-Id: <9407020213.AA21955@simd.stanford.edu> To: simpson@math.psu.edu Cc: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Fri, 1 Jul 1994 18:20:43 -0400 <199407012220.SAA14328@boole.math.psu.edu> Subject: something to think about Status: O Since I still got a few minutes to make this quick response before leaving for vacation, here's a quick comment. >Yet another example is EHZ, which offers infinite expansion >possibilities can't decide between CNS (an unpopular high-road >standard) and Big5 (a popular low-road standard). So you think EHZ's extensibility (e.g, vs. HZ+) is good or bad? What? CNS is high-road, BIG5 is low-road? What road is GB? HZ? I think Unicode, which has successfully unify GB/BIG5/JIS, etc, and most language scripts in the world, is where the future will go. The beauty of Unicode is that it gets rid of all the ugly escape sequences (yes, including ISO's, HZ's, EHZ's, etc.). However, universal Unicode support is not here yet. Until then, we have to stay with all these current "low-roads" such as ISO-2022, HZ, EHZ (including EHZ-GB, EHZ-BIG5, EHZ-CNS, EHZ-JIS), etc. It's interesting to observe that while Ricky Yeung and I want to defer the choice of BIG5/CNS to the user in the 7-bit platform, just as what they have been offered to choose in the 8-bit platform, others want to decide for the users. Ricky told me recently that he may have some free time to write some code for EHZ. I am looking forward to the release. Fung Fung Lee From cyl Sat Jul 2 00:44:30 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA16307; Sat, 2 Jul 94 00:44:30 CDT Date: Sat, 2 Jul 1994 00:44:30 -0500 (CDT) From: Nelson CHIN Subject: revise HBF Standard 1.0 now To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O i was looking through the soft-authors archives and found this, and would like to followup and ask for RFD to revise HBF standard to incorporate the suggestions and also any other previous suggestions which i may have missed since version 1.0 Nelson ---------- Forwarded message ---------- Date: Mon, 6 Jun 94 11:11 BST >From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF standard reexamined Werner Lemberg writes: > While implementing a program which uses the HBF-API, I found some problems > in the HBF Standard 1.0 and want to add some suggestions also: [documentation suggestion deleted] > o it would be nice to have error codes in the function HBF_GetBitmap() > like this (think of this as a draft for version 1.1 :-) > HBF_FILE_ERROR can't open font file for this code > HBF_INVALID_HANDLE > HBF_INVALID_CODE_RANGE > HBF_INVALID_BYTE_2_RANGE Not too difficult. > o a simple function HBF_CheckCode() to check if a specified code > is valid or not (with similar error codes to HBF_GetBitmap() ) How do you intend to use this? > o HBF should allow JIS xxxx, KS for valid HBF_CODE_SCHEME. IMHO the > format of the bitmap fonts are identical Yes -- they were designed to be. And I guess we should be using GL encodings for all these codesets. > o It is not explained exactly how to handle multiple entries of the > same keyword like HBF_CODE_RANGE if using the function > HBF_GetProperty(). I suggest to change this API-function: > int HBF_GetProperty( > OUT char * property > IN HBF_Handle handle, > IN char * propertyName ); How about just saying that the following properties are inaccessible: HBF_START_BYTE_2_RANGES HBF_BYTE_2_RANGE HBF_START_CODE_RANGES HBF_CODE_RANGE > o It should be mentioned somewhere that the COMMENT property can't > be accessed with HBF_GetProperty(). IMHO this would be senseless. Sounds reasonable. From cyl Sat Jul 2 01:45:52 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA17722; Sat, 2 Jul 94 01:45:52 CDT Date: Sat, 2 Jul 1994 01:45:51 -0500 (CDT) From: Nelson CHIN Subject: Multi-byte Code Issues mailing list available To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O For those interested in Multibyte Code Issues on an International level, send a mail to listserv@jhuvm.hcf.jhu.edu with message: subscribe iso10646 Your_Name Nelson From rap@doc.ic.ac.uk Mon Jul 4 04:00:56 1994 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA04209; Mon, 4 Jul 94 04:00:56 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qKjrI-00070kC; Mon, 4 Jul 94 09:58 BST Message-Id: Date: Mon, 4 Jul 94 09:58 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: Multi-byte Code Issues mailing list available Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O Nelson CHIN writes: > For those interested in Multibyte Code Issues on an International level, > send a mail to listserv@jhuvm.hcf.jhu.edu with message: > subscribe iso10646 Your_Name I wouldn't recommend it: now that ISO-10646 has been published, all the discussion is about rather minor points (like sorting in Spanish, whether "ae" is a ligature or a letter, should there be a code for a decimal delimiter character). Try sending GET ISO10646 LOGyymm (for appropriate yymm) to the above listserv to get a month's logs. Some of the older ones are of more interest than what's being discussed now. From handa@etlken.etl.go.jp Mon Jul 4 22:02:49 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA03144; Mon, 4 Jul 94 22:02:49 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA07138; Tue, 5 Jul 94 11:59:35 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA17174; Tue, 5 Jul 94 11:59:34 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA09710; Tue, 5 Jul 94 11:59:41 JST Date: Tue, 5 Jul 94 11:59:41 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407050259.AA09710@etlken.etl.go.jp> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu In-Reply-To: Fung Fung Lee's message of Fri, 1 Jul 1994 13:30:48 -0700 <9407012030.AA20425@simd.stanford.edu> Subject: Re: A compromise proposal Status: O I said: >>Ah! From your draft, I had got an impression that proposal >>of EHZ-BIG5 means Big5 should be mapped here. But, your >>real intention is to allow user (or programmer) to select >>what they want among EHZ-XXX (or even mixture of them) to >>encode whatever codes. Am I right? lee@simd.stanford.edu (Fung Fung Lee) said: > What can be done with EHZ should be clear from the examples > from my spec. Which example? I couldn't find any examples which suggest that user may select EHZ-CNS to encode his Big5 text. I said: >>But, on this point of view, mapping method of HZ+S provides >>the simplest way. There must be some reason for your >>prefering EHZ-BIG5 to HZ+S. Could you explain it? lee@simd.stanford.edu (Fung Fung Lee) said: > The rationale of my choice is the "anchoring principle" as explained > in my spec. But, there's no description why that principle is necessary. If the code ordering differs between EHZ-CNS and EHZ-BIG5, what's the merit of those sharing the same 7-bit code point? lee@simd.stanford.edu (Fung Fung Lee) said: > Again, you are not quoting some of my statements in the previous message. > I was just trying to follow your line of reasoning to expose some of its > logical consequence, which is NOT desirable. I can't see what's wrong with my previous response. ------------------------------------------------------------ I said: >>>>If both EHZ-CNS and EHZ-BIG5 are used, the process won't be >>>>facilitated, because there seems to be no reason for Big5 >>>>users to use EHZ-CNS instead of EHZ-BIG5. lee@simd.stanford.edu (Fung Fung Lee) said: >>> You are probably right. If you are right, why not just support EHZ-BIG5 >>> and NO EHZ-CNS ? I said: >>With only EHZ-BIG5, CNS can't be supported. ------------------------------------------------------------ My last statement just means "EHZ-BIG5 may be enough for Big5 users but it's not enough for CNS usrers." Anyway, I'm trying to quote only necessary parts for discussion to reduce the trafic. lee@simd.stanford.edu (Fung Fung Lee) said: >>> However, I'm not so sure you're right. Why not let the >>> USERS decide what they want to use, EHZ-BIG5 or EHZ-CNS? I said: >>To allow users to decide them, we must, at first, provide >>both methods of Big5<->EHZ-BIG5 and >>Big5<->EHZ-CNS/EHZ-BIG5(plane0)[/EHZ-JIS]. Are you >>proposing that all softs which support EHZ must provide both >>of them and must provide a switch for users to select them? >>Then, soft writers load gets higher than supporting only >>HZ-EA[-2]. lee@simd.stanford.edu (Fung Fung Lee) said: > I have never said anything about software implementation related to > EHZ so far. All I have focused on is the EHZ specification. But, you said "Why not let the USERS decide what they want to use, EHZ-BIG5 or EHZ-CNS?", which logically suggests that users should have opportunity to do the selection and it is possible only when soft writers write such code. I said: >>You mean that the reason you choose Plane1&2 instead of >>Plane0 is that you want the possibility of Plane0 being used >>to be low? Why is it important provided that you support >>Plane0? >> >>In the case of HZ-EA-2, I must choose Private (or Plane0) >>area for vendor part because there's no other area. Private >>area can be used also for vendor part of GB and CNS if they >>exist. lee@simd.stanford.edu (Fung Fung Lee) said: > No one can prevent you or anyone else from trying it out for field testing. Could you please respond to my question more directly/clearly? I just want to know your intention behind EHZ-BIG5. So far, I've written as clearly as possible in the range of my English ability (although it is not that good). I said: >>The reason is that I think it's better to map Big5 common >>part to CNS if we are going to support both Big5 and CNS. lee@simd.stanford.edu (Fung Fung Lee) said: > I see this as YOUR reason to promote HZ-EA (a MISNOMER by itself as > you have previously confessed to Dr. Yeung's question), but I don't > see it as the reason for HZ-EA-2. Why? Both HZ-EA and HZ-EA-2 "map Big5 common part to CNS". They only differ in the way of handling vendor part. --- Ken'ichi HANDA handa@etl.go.jp From cyl Tue Jul 5 10:04:21 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA21994; Tue, 5 Jul 94 10:04:21 CDT Date: Tue, 5 Jul 1994 10:04:20 -0500 (CDT) From: Nelson CHIN Sender: Nelson CHIN Reply-To: Nelson CHIN Subject: HBF draft coming soon To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Status: O a full draft revised from HBF standard version 1.0 will be released soon=20 for comments and based on X11R6 BDF/XLFD=20 What do you guys want in this coming HBF revision? Any volunteers for drafting, since mcpong is busy these days. for postscript reference, get ftp://ftp.x.org/pub/R6untarred/xc/doc/hardcopy/BDF,XLFD The HBF standard has said that using commpressed bitmap files may be=20 considered in a future version.. should we implement it now? how to go=20 about using gzipped bitmap files? ---------- Forwarded message ---------- Date: Tue, 5 Jul 94 11:11:05 HKT >From: Dr. Man-Chi PONG To: Nelson CHIN Subject: Re: HBF Standard (fwd) I also don't have time (and very inconvenient to access the HBF Standard source file kept at cs.ust.hk) to do the update. If you're interested, you can update the HBF Standard; and say, call it version 1 release 2 (assuming the previous release no. is 1). BTW, I've also unsubscribed soft-authors. --=20 mcpong -- in GB2312-80:~{=C5=D3=C3=F1=D6=CE~}, in Big5: =C3e=A5=C1=AAv From simpson@math.psu.edu Tue Jul 5 18:11:26 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA11181; Tue, 5 Jul 94 18:11:26 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id TAA12520; Tue, 5 Jul 1994 19:09:04 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 5 Jul 1994 19:09:02 -0400 Date: Tue, 5 Jul 1994 19:09:02 -0400 Message-Id: <199407052309.TAA24815@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: something to think about In-Reply-To: <9407020213.AA21955@simd.stanford.edu> References: <199407012220.SAA14328@boole.math.psu.edu> <9407020213.AA21955@simd.stanford.edu> Reply-To: simpson@math.psu.edu Status: O Fung wrote: > So you think EHZ's extensibility (e.g, vs. HZ+) is good or bad? In the abstract, EHZ's extensibility is a good thing. However, EHZ pays a price for it. The price is: (1) more complicated escape sequences: ~{~g instead of ~>, redundancy of ~{ and ~A, etc. (2) lack of clarity about CNS versus Big5. Big5 users are not told whether to use EHZ-Big5 or EHZ-CNS or EHZ-CNS-JIS. (3) lack of neutrality as between Big5 and GB, since GB is the default non-ASCII mode. > CNS is high-road, BIG5 is low-road? Yes. Big5 is low-road only, because it is popular but has no official standing. CNS is high-road only, because it is officially recognized but unpopular. > What road is GB? HZ? GB can travel on both the high road and the low road. GB is suitable for the high road, because (1) GB is an official, internationally recognized standard, (2) GB fits into the 2-byte graphical ASCII range, 0x2121 to 0x7E7E, which makes it suitable as an ISO-2022 recognized character set. GB is also suitable for the low road, because GB is very popular and widely used. HZ is based on GB. However HZ uses escape sequences ~{, ~} which are not quite compatible with ASCII, and this means that HZ is unlikely to ever achieve official international recognition. So I regard HZ as a very pragmatic, successful, low-road solution, with some high-road aspects thanks to its close relationship with GB. If only there were a coding system for traditional Chinese characters that were both popular and officially recognized, like GB for simplified characters! Unfortunately, no such coding system exists. We must choose between Big5 (popular and unofficial) versus CNS, ISO-2022, and Unicode (unpopular and official). Hence the importance of the crucial distinction between the low road and the high road. > It's interesting to observe that while Ricky Yeung and I want to > defer the choice of BIG5/CNS to the user in the 7-bit platform, > just as what they have been offered to choose in the 8-bit platform, > others want to decide for the users. I don't want to decide for the users. If users want to use CNS or ISO-2022 or Unicode, let them do so with my blessing. However, I believe that the Internet needs a simple, 7-bit standard for mixed ASCII, GB, and Big5. This and nothing more is what HZ+ provides. -- Steve From lai@apple.com Tue Jul 5 20:26:05 1994 Return-Path: Received: from apple.com by ifcss.org (4.1/IFCSS-Mailer) id AA14905; Tue, 5 Jul 94 20:26:05 CDT Received: from [17.203.80.11] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA06826; Tue, 5 Jul 94 18:23:37 -0700 for soft-authors@ifcss.org Date: Tue, 5 Jul 94 18:23:37 -0700 Message-Id: <9407060123.AA06826@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org From: lai@apple.com (Edmund Lai) Subject: Re: A compromise proposal Status: O As an extension to HZ, Kenichi Handa's proposal make a lot of sense. As a completely new Chinese exchange standard, then Ross Paterson's proposal of using 7 bit encoding for Unicode make a lot of sense. So it is a matter of whether we want an evolution or a revolution. I suspect at this point evolution may be more acceptable to a lot of people than a revolution. Both proposals have been critizied as requiring translating requiring a lookup table (although the CNS<->Big5 lookup table can be very small). But the fact is that other proposal to extend HZ already effectively involve Big5<->GB translation, which is much messier. By this I mean most people discuss the issue seem to believe that all that is invovled is that when you encountered an escape sequence, you translate that into GB or Big5 or ASCII, and then that is done. However as Avron Boretz pointed out a while ago: >2) Whatever is finally decided, the solution should take into account how >most real users work on the net. For example, without having taken a >scientific poll or anything, it's probably safe to say that most end users >who will want access to this kind of function (at Cornell I'd estimate >that would break down to about 60% native Chinese-speaking >students/scholars and 40% native English-speaking students/scholars) will >be reading news using either a dedicated browser on a Mac with the Chinese >Language Kit or a Windows (Winsock) PC running Chinese Windows or >Twinbridge, or Mosaic. They will be reading their mail using a POPmail >client like Eudora or Windows Eudora. In this scenario, the user simply >selects the Chinese system font to read Big5 text. That certainly is my own experience. I am using Eudora for mail and NewsWatcher for news. Most people out there are using GB only or Big5 only in their PC. The Mac can have both at the same time but not everyone install both. And even if both are installed the fact that Eudora and NewsWatcher only support a single font at a time means that only Big5 or GB can be used in a single article and not both. One may say this is Eudora and NewsWatcher's fault, but like it or not, it is the kind of software people are using now. In the Chinese newsgroup, we should expect someone to post an article in GB, then someone read it and response in Big5. I expect to be able to read the original message mixed with the response in the same article. This is what we are getting right now with the mirroring of the GB and Big5 group. This is the mininum we should expect for any extension to HZ, otherwise it is not worthwhile extending it. That is why effectively Big5<->GB is a requirement for most people. If the software is translating between Big5<->GB, then translating between CNS<->Big5 or Unicode<->Big5/GB should not be considered to be an issue. /* Disclaimer: All statments and opinions expressed are my own */ /* Edmund K. Lai */ /* Apple Computer, MS303-3A */ /* 20525 Mariani Ave, */ /* Cupertino, CA 95014 */ /* (408)974-6272 */ zW@h9cOi From lee@simd.stanford.edu Wed Jul 6 00:49:48 1994 Return-Path: Received: from simd.stanford.edu by ifcss.org (4.1/IFCSS-Mailer) id AA23371; Wed, 6 Jul 94 00:49:48 CDT Received: by simd.stanford.edu (5.65/inc-1.0) id AA17722; Tue, 5 Jul 1994 22:46:41 -0700 Date: Tue, 5 Jul 1994 22:46:41 -0700 From: lee@simd.stanford.edu (Fung Fung Lee) Message-Id: <9407060546.AA17722@simd.stanford.edu> To: handa@etlken.etl.go.jp Cc: soft-authors@ifcss.org In-Reply-To: Kenichi Handa's message of Tue, 5 Jul 94 11:59:41 JST <9407050259.AA09710@etlken.etl.go.jp> Subject: A compromise proposal Status: O >Date: Tue, 5 Jul 94 11:59:41 JST >From: handa@etlken.etl.go.jp (Kenichi Handa) >Which example? I couldn't find any examples which suggest >that user may select EHZ-CNS to encode his Big5 text. I see the main problem of EHZ is to define some new 7-bit code spaces for some hanzi, especially Chinese, 8-bit code schemes, specifically GB, BIG5, and CNS (Yes, there are 8-bit versions of CNS). How the various codes can be translated among themselves is NOT a new problem. This problem clearly exists independent of the 7-bit/8-bit issue. As the co-author of HC (Hanzi Converter: GB<->BIG5), you bet I know something about this problem, specifically, the vendor/user-defined parts of BIG5. My recommendation is to avoid the GB/BIG5/CNS translation issue as much as possible in the definition of EHZ, and leave the translation issue to the implementation. In practice, if a user has access to BIG5->EHZ-CNS encoder, he can post in EHZ-CNS, or similarly he can post in mixed EHZ-CNS, EHZ-GB and EHZ-JIS as you suggested, although what you suggested is just one of the possible mappings in general, because it is not uncommon to find a hanzi that exists in the character sets of GB, CNS, BIG5 and JIS. Newsgroup organizers may impose on top of EHZ additional convention about what subsets of EHZ should be posted in which newsgroups. This design tries to give maximum flexibility to the user while maintaining the stability of the EHZ spec. It consciously leaves the decision of what subsets of EHZ should be used to the user, and the Chinese Internet community, in view of no easy unanimous consensus is in sight!!! Given that one needs 8-bit CNS<->BIG5 converter anyway, the extra overhead in supporting EHZ-BIG5 in addition to EHZ-CNS is minimal. If EHZ-BIG5 or EHZ-CNS proves to be worthless in all circumstances (which I doubt), at least this can be found out empirically by experiment rather than by debate. Regardless of the outcome, nothing needs to be changed in the EHZ standard. The worst case is perhaps wasting 2 or 3 escape sequences (~G, ~H vs. ~f, ~g, ~h), but there are plenty left in the EHZ framework, which is not the case in other non-EHZ proposals, such as HZ+. I don't see why we can't afford to do the experiments under the framework of EHZ. (I can see why we can't afford to do the experiments in a "HZ+"-like scheme.) That's why I am so anxiously waiting for Ricky's EHZ implementation. Again, I urge Mr. Handa not to use the terms HZ-EA[-2] anymore, as he agreed to do so with Ricky Yeung last week in reponse to my posting. If I understand his proposal correctly, his HZ-EA is NOT proposing any new standard, he was proposing a method or a convention of how to encode BIG5 with EHZ-GB,EHZ-CNS,EHZ-JIS. As all four code spaces are well-defined, I don't count that as defining some new EHZ code space. What he proposed is that EHZ-BIG5 should NOT exist. As for his second proposal, the HZ-EA-2 compromise, he was effectively suggesting a re-defintion of EHZ-CNS, adding new code spaces in EHZ-CNS, to which there were no correspondence in CNS. If Mr. Handa agreed to my interpretation, I urge him to label his proposals more carefully, e.g. HZ-EA -> Handa's proposal 1 HZ-EA-2 -> Handa's proposal 2 Of course, it really should be Ricky Yeung who should be more concerned. :-) >But, there's no description why that principle is necessary. >If the code ordering differs between EHZ-CNS and EHZ-BIG5, >what's the merit of those sharing the same 7-bit code point? Had the CNS committee not re-ordered/ inserted / deleted the BIG5 characters, don't you think EHZ-CNS and EHZ-BIG5 would become identical? One of my goals is to make this contrast more obvious in EHZ-BIG5, than in HZ+. (Granted, you may not agree this goal is necessary, just as someone may not agree maximal ASCII transparency is very important.) Before I knew about the structure of CNS, I was actually inclined to HZ+S and Yagui Wei's HZ-2. But now I feel more comfortable with the "anchoring" principle. I see this is actually a compromise of BIG5 mapping anchoring "to" CNS. Anyway, even though I don't agree with your proposals and their improper naming, your implementation will still be welcome, as I see it as providing some tools for performing exactly the kind of experiments I repeatedly encouraged in this forum. >Anyway, I'm trying to quote only necessary parts for >discussion to reduce the trafic. Frankly, I have more fun replying to your mail than replying to some one else who has kept playing tricks on words. For something to be successful, a great idea is not sufficient. It needs some stronger backers behind it. In contrast, a successful idea is not necessarily a great idea. It may become successful mainly due to its strong backers. Anyway, the time I've spent on this HZ extension topic has far exceeded what I intended to spend. It's time for me to take a break. :-) Fung Fung Lee From simpson@math.psu.edu Wed Jul 6 10:09:58 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA08499; Wed, 6 Jul 94 10:09:58 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA18015; Wed, 6 Jul 1994 11:07:36 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Jul 1994 11:07:35 -0400 Date: Wed, 6 Jul 1994 11:07:35 -0400 Message-Id: <199407061507.LAA25892@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: reply to Yuan's points about vendor-specific Big5 In-Reply-To: <9407030237.AA17068@ifcss.org> References: <9407030237.AA17068@ifcss.org> Reply-To: simpson@math.psu.edu Status: O Yuan Jiang writes: > Agree, the vendor-dependent/user-defined Big5 code is the thorn. Vendor-specific and user-specific Big5 codes are not a problem for HZ+ or for similar schemes such as HZ-2, B5E*, EHZ-Big5, etc. HZ+ et al handle them with ease. Vendor-specific Big5 is only a problem for people like you and Ed Lai, who mistakenly believe that CNS is a good medium for transmitting Big5. > There is no way to support it and make most people happy. I disagree. There is no reason why supporting it should make anyone unhappy. If the existence of vendor-specific Big5 codes makes you and Ed unhappy, that is a problem for you and Ed, not a problem for HZ+. In any case, the goal of HZ+ is not to make everybody happy. The goal is rather to provide a convenient 7-bit transmission standard for mixed ASCII, GB, and Big5. In this goal HZ+ succeeds very well. > For a low road, why cann't we drop its support at this moment? The reason we can't drop it is that the success of any low-road standard depends on its ability to meet the needs of users. Vendor-specific Big5 is part of Big5, and users need excellent Big5 support. > How many people will benefit from its support anyway? In a narrow sense, I have no statistics on how many people actually use vendor-specific or user-specific features of Big5. Nelson pointed out that ETen-specific Big5 is used in Taiwanese newsgroups, e.g. Japanese kana in mirrors of Japanese newsgroups. Also, ETen Big5 includes graphical characters used in drawing boxes for tables, etc. I have used this stuff and I'm sure others have too. In a wider sense, all users of HZ+ will benefit if HZ+ is widely used, and for HZ+ to be widely used it must first and foremost provide excellent Big5 support. So in this sense all users of HZ+ will benefit, even users who do not themselves make use of vendor-specific features. -- Steve From simpson@math.psu.edu Wed Jul 6 14:18:56 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA20307; Wed, 6 Jul 94 14:18:56 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA19813; Wed, 6 Jul 1994 15:16:14 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Jul 1994 15:16:13 -0400 Date: Wed, 6 Jul 1994 15:16:13 -0400 Message-Id: <199407061916.PAA26894@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: answer to Ross's question In-Reply-To: <199407011519.LAA12796@leibniz.math.psu.edu> References: <199407011519.LAA12796@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Ross Paterson writes: > ... something I haven't understood about how the HZ > extensions are to work. Is it true that most people use 'monolingual' > systems where at any point 8-bit bytes are interpreted as ASCII plus > something else, such as GB or Big-5? Yes, I think this is what most people use. I am talking about popular Chinese software for MSDOS and Macintosh, as well as things like cxterm for Unix. > If so, the reading software will have to incorporate a table-driven > mapping of any characters in the other character set to the native > set. Steve mentioned how to do this under Unix with a 3-stage > pipeline. Is this conversion any problem to do on-the-fly on other > systems? I think Ross is referring to 3-stage pipelines as in for example cat file.hzp | hzp2gb | gb2big | hzp2big -8 > file.big for a Big5 user, in case file.hzp contains both GB and Big5 data. Under MSDOS, the same pipelines are valid (you have to say "type" instead of "cat"). However, MSDOS doesn't support asynchronous processes, so it may not be so easy to invoke these pipelines on-the-fly from within application programs. Until the conversion routines are incorporated in application software, I guess the user will have to "escape to DOS" and run the pipeline as a standalone program (implemented as a shell script, or "batch file" in MSDOS terminology). As for Macintosh, I don't know. I have never touched a Mac. I'm not even sure whether MacOS has well-defined notions of pipes or redirection or even files. My impression is that MacOS is quite sophisticated, so I would imagine it contains equivalent capabilities. Could someone please enlighten us? John? Ed? -- Steve From simpson@math.psu.edu Wed Jul 6 14:49:55 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22157; Wed, 6 Jul 94 14:49:55 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA20028; Wed, 6 Jul 1994 15:47:32 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Jul 1994 15:47:30 -0400 Date: Wed, 6 Jul 1994 15:47:30 -0400 Message-Id: <199407061947.PAA26941@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: HZ+: new release Reply-To: simpson@math.psu.edu Status: O The two most popular Chinese character coding schemes are GB and Big5. There is urgent need for a simple, practical, 7-bit representation of mixed ASCII, GB, and Big5 for use on the Internet. HZ+ is my proposal to meet this need. A new release of the HZ+ specification document and sample implementation is now available. It is at ftp.math.psu.edu, /pub/simpson/chinese/hzp. Unix source code and MSDOS executables are provided. New features: (1). Optional support for the ETen Big5 user area 0x8140-A0FE is now part of the HZ+ spec, although not implemented in the sample implementation. (2). Only GB and Big5 are supported. The idea that HZ+ might someday support CNS is no longer mentioned. CNS support has been removed from the sample implementation. -- Steve From simpson@math.psu.edu Wed Jul 6 17:14:49 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA29043; Wed, 6 Jul 94 17:14:49 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id SAA21181; Wed, 6 Jul 1994 18:12:31 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 6 Jul 1994 18:12:29 -0400 Date: Wed, 6 Jul 1994 18:12:29 -0400 Message-Id: <199407062212.SAA27117@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: technical questions about EHZ In-Reply-To: <9406290654.AA16739@hk.Eng.Sun.COM> References: <199406241718.NAA21371@boole.math.psu.edu> <9406290654.AA16739@hk.Eng.Sun.COM> Reply-To: simpson@math.psu.edu Status: O I posted some technical questions about Fung's EHZ specification. Ricky Yeung replied, but I don't find the reply very informative. Would Fung or Ricky please clarify further? Or would someone else care to try? I wrote: > 3. In the following excerpt from the EHZ spec, what is the meaning of > the prefixes 20, 21, 22? Ricky replied: > >From Fung Lee's document: > 'beyond the end of Plane 1 (217D7E, 0x7D7E of Plane 1). Hence, a mapping' > It should be easy to infer the meaning of the prefixes: > 20 - Plane 0 > 21 - Plane 1 > 22 - Plane 2 > Aparently you got the meaning since you used it correctly in your > mapping questions below. Well, yes, I guessed that this was something like Fung's intention. But my real question is, why? Why does 20 mean "plane 0" etc.? Is this some kind standard computer science terminology? I don't feel confident in using this kind of notation until I know its true meaning. I wrote: > Finally, some technical questions about the EHZ-Big5 mapping itself. followed by a series of technical questions. Ricky replied: > I think you can easily find the answers to your mapping questions (with > some simple arithmetics) if you did not quote Fung Lee's document in the > way you did. I read Fung's document very carefully several times, but I was not able to find the answers to my questions. That's why I posted the questions. What I found in Fung's document was some rather sketchy reasoning about anchor points, the desirability of non-overlapping Big5 and CNS code ranges, etc. This reasoning didn't make much sense to me. I'd like a more detailed explanation. Why is it desirable for CNS and Big5 to share the same anchor points? What advantage (if any) is gained? If there is an advantage, why is it worth the consequent arbitrariness and loss of simplicity? -- Steve From Ricky.Yeung@Eng.Sun.COM Wed Jul 6 20:55:22 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA06510; Wed, 6 Jul 94 20:55:22 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10445; Wed, 6 Jul 94 18:53:08 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23979; Wed, 6 Jul 94 18:54:16 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA03500; Wed, 6 Jul 1994 18:54:19 +0800 Date: Wed, 6 Jul 1994 18:54:19 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407070154.AA03500@hk.Eng.Sun.COM> To: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Tue, 5 Jul 1994 19:09:02 -0400 <199407052309.TAA24815@boole.math.psu.edu> Subject: Re: something to think about Content-Length: 2779 Status: O > From: Stephen G Simpson > Date: Tue, 5 Jul 1994 19:09:02 -0400 > > Fung wrote: > > So you think EHZ's extensibility (e.g, vs. HZ+) is good or bad? > > In the abstract, EHZ's extensibility is a good thing. However, EHZ > pays a price for it. The price is: (1) more complicated escape > sequences: ~{~g instead of ~>, redundancy of ~{ and ~A, etc. (2) lack > of clarity about CNS versus Big5. Big5 users are not told whether to > use EHZ-Big5 or EHZ-CNS or EHZ-CNS-JIS. (3) lack of neutrality as > between Big5 and GB, since GB is the default non-ASCII mode. I thought we settled that long ago. (1) As I pointed out, ~{ and ~A are not redundant because they have different semantics. I already explicitly pointed out your misconception about this about a month ago. Moreover, there is some subtle difference between the meanings of ~{~g and ~> (or ~1, BTW, which escape sequence are you going to stick to? They seem to be switching constantly). (2) If your "lack of clarity about CNS versus Big5" means that the EHZ framework doesn't exclusively pick/forbid Big5 or CNS, you should read Dr. Fung Fung Lee's messages on this issue. It's NOT a 7-bit exchange code problem; the same old problem exists on their 8-bit counterparts. Why try to solve it altogehter as there won't be any consensus? Of course, Big5 users are not TOLD by the framework to use which EHZ mapping, it's their choice (and the software available to them). (3) Again, as I pointed out before, EHZ provides equal ASCII transparency (compared to HZ) for all the coding schemes while others, like HZ+S, don't. In this sense, EHZ is more neutral. (Didn't we spend a lot of bandwidth on this "policitical" issue of "fairness"?) [ ... stuff deleted ... ] > > It's interesting to observe that while Ricky Yeung and I want to > > defer the choice of BIG5/CNS to the user in the 7-bit platform, > > just as what they have been offered to choose in the 8-bit platform, > > others want to decide for the users. > > I don't want to decide for the users. If users want to use CNS or > ISO-2022 or Unicode, let them do so with my blessing. However, I > believe that the Internet needs a simple, 7-bit standard for mixed > ASCII, GB, and Big5. This and nothing more is what HZ+ provides. The EHZ framework does all that with better ASCII transparency and provides flexibility for incorporating other codes in the future in a simple way. As for the mappings, comparing Dr. Fung Fung Lee's EHZ-Big5 with that of HZ+S (and others), so far I find Fung Fung Lee's design more compelling because it reflects the structure of Big5, and his "anchoring principle" makes a lot more sense to me. -Ricky From handa@etlken.etl.go.jp Thu Jul 7 07:01:29 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA23426; Thu, 7 Jul 94 07:01:29 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA16105; Thu, 7 Jul 94 20:56:07 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA25142; Thu, 7 Jul 94 20:56:07 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA11238; Thu, 7 Jul 94 20:56:13 JST Date: Thu, 7 Jul 94 20:56:13 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407071156.AA11238@etlken.etl.go.jp> To: lee@simd.stanford.edu Cc: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu In-Reply-To: Fung Fung Lee's message of Tue, 5 Jul 1994 22:46:41 -0700 <9407060546.AA17722@simd.stanford.edu> Subject: Re: A compromise proposal Status: O I said: >>Which example? I couldn't find any examples which suggest >>that user may select EHZ-CNS to encode his Big5 text. lee@simd.stanford.edu (Fung Fung Lee) said: > I see the main problem of EHZ is to define some new 7-bit code spaces > for some hanzi, especially Chinese, 8-bit code schemes, specifically > GB, BIG5, and CNS (Yes, there are 8-bit versions of CNS). How the > various codes can be translated among themselves is NOT a new problem. > This problem clearly exists independent of the 7-bit/8-bit issue. > As the co-author of HC (Hanzi Converter: GB<->BIG5), you bet I know > something about this problem, specifically, the vendor/user-defined > parts of BIG5. > My recommendation is to avoid the GB/BIG5/CNS translation issue > as much as possible in the definition of EHZ, and leave the translation > issue to the implementation. As I wrote before, from my point of view, Big5 should be regarded as not a character set but as an encoding methods of (part of) several character sets (including ASCII). In this sense, Big5 -> EHZ-CNS is not a translation but a conversion of encoding methods just like that EUC-GB (8-bit GB) -> EHZ-GB is not a translation but a conversion. And, of course, EUC-GB is not a character set but an encoding methods of two character sets GB2312 and ASCII. Once one sees Big5 in this way, he will not have any mental resistance in exchanging Big5 with EHZ-CNS (and mixture of other EHZ-XXX). I'd like to ask everyone to consider the current problem from this point of view. I believe it brushes off the unclearness which one feels while considering the problem of Big5 and CNS. lee@simd.stanford.edu (Fung Fung Lee) said: > Again, I urge Mr. Handa not to use the terms HZ-EA[-2] anymore, as he > agreed to do so with Ricky Yeung last week in reponse to my posting. I'm waiting alternative names, but the one proposed by him (was it `Restricted EHZ'?) met opposition, and he has not yet replied to it. > If I understand his proposal correctly, his HZ-EA is NOT proposing > any new standard, he was proposing a method or a convention of how to encode > BIG5 with EHZ-GB,EHZ-CNS,EHZ-JIS. Yes. > As all four code spaces are well-defined, > I don't count that as defining some new EHZ code space. I didn't clearly mentioned about `Private' area in my first proposal, but, perhaps, `Private' area will be a new code space because I don't want it used only for Big5. I want to use this area also for vendor-code of GB or CNS if they really exit. > As for his second proposal, the HZ-EA-2 compromise, he was effectively > suggesting a re-defintion of EHZ-CNS, adding new code spaces in EHZ-CNS, > to which there were no correspondence in CNS. I didn't suggest re-defintion of EHZ-CNS, but suggested new spaces `Private' (perhaps to be named EHZ-Private or EHZ-PRV). > If Mr. Handa agreed to my interpretation, I urge him to label his proposals > more carefully, e.g. > HZ-EA -> Handa's proposal 1 > HZ-EA-2 -> Handa's proposal 2 > Of course, it really should be Ricky Yeung who should be more concerned. :-) Hmm, a simple idea. I now feel some attachment for HZ-EA[-2] and am bashful for using my name, but, ok, let's call them Handa-1 and Handa-2 for short. I said: >>But, there's no description why that principle is necessary. >>If the code ordering differs between EHZ-CNS and EHZ-BIG5, >>what's the merit of those sharing the same 7-bit code point? lee@simd.stanford.edu (Fung Fung Lee) said: > Had the CNS committee not re-ordered/ inserted / deleted the BIG5 > characters, don't you think EHZ-CNS and EHZ-BIG5 would become identical? > One of my goals is to make this contrast more obvious in EHZ-BIG5, than > in HZ+. (Granted, you may not agree this goal is necessary, just as > someone may not agree maximal ASCII transparency is very important.) I now understand your intention on this matter and I agree with the necessity of that goal. But I'm still in doubt about the effect of `anchoring principle', it's halfway. As I wrote before, moving vendor area also to Private is more effective, and using Handa-2 (what a tickling, I hope I get used to it soon :-)) is much more effective. > Anyway, even though I don't agree with your proposals and their improper > naming, your implementation will still be welcome, as I see it as providing > some tools for performing exactly the kind of experiments I repeatedly > encouraged in this forum. I heard that my mail entitled "HZ-EA encoder/decoder" which contains the actual program for Handa-1 and Handa-2 didn't reach to someone on this mailing-list. Did you get it? It was around 20k bytes. Are there any limit on the length of mails in this list? Should I post it again with smaller pieces? > For something to be successful, a great idea is not sufficient. > It needs some stronger backers behind it. > In contrast, a successful idea is not necessarily a great idea. > It may become successful mainly due to its strong backers. Yes, and I do want many strong backers of my proposals. > Anyway, the time I've spent on this HZ extension topic has far > exceeded what I intended to spend. It's time for me to take a break. :-) While many people are approving your idea, they won't allow you to take a rest. :-) --- Ken'ichi HANDA handa@etl.go.jp From handa@etlken.etl.go.jp Thu Jul 7 23:28:34 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA28830; Thu, 7 Jul 94 23:28:34 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA21585; Fri, 8 Jul 94 13:26:10 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA02293; Fri, 8 Jul 94 13:26:09 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA11620; Fri, 8 Jul 94 13:26:16 JST Date: Fri, 8 Jul 94 13:26:16 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407080426.AA11620@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Kenichi Handa's message of Thu, 7 Jul 1994 20:56:13 JST <9407071159.AA05417@sutgate.bitnetjp.ad.jp> Subject: Re: A compromise proposal Status: O Just to avoid misunderstanding... On Thu, 7 Jul 1994 20:56:13 JST, Kenichi Handa said: >> If I understand his proposal correctly, his HZ-EA is NOT proposing >> any new standard, he was proposing a method or a convention of how to encode >> BIG5 with EHZ-GB,EHZ-CNS,EHZ-JIS. > Yes. I meant "No". I wanted to say "You are right." This is one of common mistakes done by Japanese... :-( --- Ken'ichi HANDA handa@etl.go.jp From cyl Fri Jul 8 14:26:52 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA28923; Fri, 8 Jul 94 14:26:52 CDT Date: Fri, 8 Jul 1994 14:26:51 -0500 (CDT) From: Nelson CHIN Subject: high road 7-bit exchange utilities To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O for those of you who are high road focused, some prototype big5 <-> utf7 and gb <-> utf7 conversion utilities by Ross are now available at ifcss.org:/software/unix/convert/utf7.tar.gz, and its own utf/ subdirectory for those of you on other platforms who wish to inspect the code, and maybe port to non-unix applications. Nelson Chin From simpson@math.psu.edu Fri Jul 8 15:03:32 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA01769; Fri, 8 Jul 94 15:03:32 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id QAA14315; Fri, 8 Jul 1994 16:00:56 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 8 Jul 1994 16:00:54 -0400 Date: Fri, 8 Jul 1994 16:00:54 -0400 Message-Id: <199407082000.QAA06908@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: reply to Yuan's points about vendor-specific Big5 Newsgroups: alt.chinese.computing In-Reply-To: <199407062247.PAA26290@alumni.caltech.edu> References: <9407030237.AA17068@ifcss.org> <199407061512.KAA26471@news.cs.utexas.edu> <199407062247.PAA26290@alumni.caltech.edu> Reply-To: simpson@math.psu.edu Status: O Daniel R. Kegel writes: > but isn't it a problem that people with incompatible vendor-specific > big5's can't exchange text that uses the extension? Yes, that's a problem. But it's a problem that is inherent to GB, Big5, or any other popular standard that admits vendor-specific extensions. If Unicode ever becomes popular, then Unicode will also have the same problem. HZ+ and similar proposals (HZ-2, B5E*, EHZ-Big5) do not solve that problem, but they also do not make that problem any worse. > Is this "excellent" support? Yes, it is. Please remember the meaning of the word "excellent". "Excellent" means "much better than the competitors". In this case, I was talking about HZ+'s support for Big5 by means of a simple mapping to the 7-bit code space. The competing proposal is to support Big5 by means of translation into CNS. I am claiming that HZ+'s Big5 support is much, much better. One reason why HZ+'s Big5 support is much, much better is that it guarantees 100 percent round-trip accuracy, no matter which vendor's Big5 extension is being used. CNS translation cannot achieve anything like this kind of accuracy. > Here's the real question. For each vendor's big5 variant, is it > possible to find a mapping to and from a standard exchange code > (e.g. unicode)? I'd love to hear some real counterexamples to > this. This is *a* question, but I don't think it's the only question you should focus on. I don't even think it's a very interesting question. The truth is that nobody can ever give a definitive answer to this question, because nobody can predict what future Big5 variants or future exchange code standards will look like. HZ+ neatly side-steps this question, by guaranteeing 100 percent accuracy for each Big5 variant, independent of which Big5 variant we are talking about. Please remember that the goal of HZ+ is to provide a convenient representation of mixed ASCII, GB, and Big5 text for use on the Internet. I sincerely believe that HZ+ is the best short-term way to achieve this goal. If you don't think this is an important goal, then you have no reason to be interested in HZ+. -- Steve From simpson@math.psu.edu Fri Jul 8 15:25:04 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA02811; Fri, 8 Jul 94 15:25:04 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id QAA14501; Fri, 8 Jul 1994 16:22:41 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 8 Jul 1994 16:22:40 -0400 Date: Fri, 8 Jul 1994 16:22:40 -0400 Message-Id: <199407082022.QAA06938@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: UHZ problem In-Reply-To: <199407080723.DAA10052@leibniz.math.psu.edu> References: <199407080723.DAA10052@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Doug Schiffer writes: > I was playing with some sample code to convert various Chinese > language standards (Big5, GB, etc) to UHZ when I ran into a problem: > The escape terminator that I used is itself a valid UHZ codestring > . The problem stems from the fact that UHZ, like the HZ > standard it is derived from, uses ALL printable ASCII codepoints to > encode characters. It also uses these same codepoints to denote the > escape terminator. > ... > ** Note that this same problem lurks in other HZ extension proposals. ** This problem doesn't lurk in HZ+. HZ+ does not have this problem, because the HZ+ code range is 0x2121-7D7E, not 0x2121-7E7E. -- Steve From simpson@math.psu.edu Fri Jul 8 16:36:20 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA06211; Fri, 8 Jul 94 16:36:20 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id RAA14942; Fri, 8 Jul 1994 17:34:04 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 8 Jul 1994 17:34:03 -0400 Date: Fri, 8 Jul 1994 17:34:03 -0400 Message-Id: <199407082134.RAA07025@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: Re: A compromise proposal In-Reply-To: <199407060127.VAA14126@leibniz.math.psu.edu> References: <199407060127.VAA14126@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Edmund Lai presented a lot of verbiage leading up to the following conclusion: > ... translating > between CNS<->Big5 or Unicode<->Big5/GB should not be considered > to be an issue. To begin with, I would like to point out that this conclusion is rather strange, especially coming from Ed. Ed's proposal to support Big5 on the Internet is precisely to do so by means of CNS<->Big5 translation (or, in Ed's terminology, "to use CNS codes as the exchange codes for Big5 codes"). Therefore, if we want to follow Ed's own suggestion, we have to consider this issue. Or, to put it in another way, if we don't want to consider CNS<->Big5 translation, then we can't take Ed's own ideas seriously. My own view is that we should seriously consider the issue of Big5<->CNS translation, and then, after considering it very seriously, we should reject it, on the grounds that it does not work very well. Now let's take a look at Ed's spurious reasoning, leading up to his peculiar conclusion that Big5<->CNS translation "should not be considered to be an issue". Ed writes: > ... the fact is that other proposal to extend HZ already effectively > involve Big5<->GB translation, which is much messier. Without the word "effectively", this statement of Ed's is flatly false. As Ed well knows, HZ+ and similar proposals do not involve any kind of Big5<->GB translation. Ed goes on to explain the word "effectively" by reference to his own experiences with Eudora and other software. His reasoning is that, since many users use only Big5 or only GB but not both, these users cannot read HZ+ coded GB except by translation to Big5, or vice versa, so therefore HZ+ "effectively involves" GB<->Big5 translation. I would like to point out that this reasoning makes no sense whatsoever. One might as well argue that the very existence of Big5 "effectively involves" Big5->GB translation, because GB users cannot read Big5 except by means of such translation. The actual truth, which Ed wants to evade, is that HZ+ provides a 100 percent accurate representation of both GB and Big5, with no GB<->Big5 translation involved. A GB user who encounters Big5 text has always had three options: (1) get some Big5 software, (2) translate the Big5 text into GB, (3) give up trying to read Big5. These options will always exist, independently of whether the Big5 text was transmitted directly (in 8-bit form) or via HZ+. The existence of Big5 may be a problem for Ed, but HZ+ did not create this problem. I have been reading Ed's postings for several months now, and frankly I have to say that I find them rather strange and illogical. I think that Ed must have some hidden motive which he is unable to reveal. Can anyone shed any light on the question of what Ed's real problem is, or what ax Ed is really trying to grind? In trying to answer this question for myself, I have been playing with several hypotheses. Two of my hypotheses are: (1) Ed hates Big5, because Big5 is a rival to his beloved GB; (2) Ed hates HZ, because HZ is a rival to his beloved zW. Does anyone have any other possible explanation? -- Steve From simpson@math.psu.edu Fri Jul 8 17:31:38 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA09030; Fri, 8 Jul 94 17:31:38 CDT Received: from leibniz.math.psu.edu by cnd.org (4.1/4.7) id AA28301; Fri, 8 Jul 94 15:28:50 PDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id SAA15194; Fri, 8 Jul 1994 18:27:10 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 8 Jul 1994 18:27:09 -0400 Date: Fri, 8 Jul 1994 18:27:09 -0400 Message-Id: <199407082227.SAA07083@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: reply to Ricky's criticisms In-Reply-To: <9407070154.AA03500@hk.Eng.Sun.COM> References: <199407052309.TAA24815@boole.math.psu.edu> <9407070154.AA03500@hk.Eng.Sun.COM> Reply-To: simpson@math.psu.edu Status: O I wrote: > In the abstract, EHZ's extensibility is a good thing. However, EHZ > pays a price for it. The price is: (1) more complicated escape > sequences: ~{~g instead of ~>, redundancy of ~{ and ~A, etc. (2) lack > of clarity about CNS versus Big5. Big5 users are not told whether to > use EHZ-Big5 or EHZ-CNS or EHZ-CNS-JIS. (3) lack of neutrality as > between Big5 and GB, since GB is the default non-ASCII mode. Ricky Yeung replied: > I thought we settled that long ago. (1) As I pointed out, ~{ and ~A are > not redundant because they have different semantics. I already > explicitly pointed out your misconception about this about a month ago. > Moreover, there is some subtle difference between the meanings of ~{~g > and ~> I find your tone rather abrasive. I'm trying to hold my temper here. You did not settle anything long ago. I don't have any misconceptions whatsoever. HZ and HZ+ use ~{ to switch into GB mode. EHZ uses both ~{ and ~A in different contexts for the same purpose. Even though there may be a subtle distinction in your mind, it is still very clear that ~{ plus ~A is more complicated by a factor of 2 than ~{ alone. You can't deny this. Similar remarks apply to HZ+'s ~> versus EHZ's ~{~g. What I am pointing out is that EHZ's escape sequences are more complicated than HZ+'s. This is obviously the case, and for you to try to deny it is silly and pointless. If you want to argue that the extra complication buy us some advantage (e.g. "maximal ASCII transparency"), I'll listen and decide for myself. But please don't try to deny the obvious. > (or ~1, BTW, which escape sequence are you going to stick to? They > seem to be switching constantly). I think I'll stick to ~>. I don't know why you say they are switching constantly. The HZ+ escape sequences changed only once, in response to a criticism having to do with C programs. Again, I find your tone rather abrasive. > (2) If your "lack of clarity about CNS versus Big5" means that the EHZ > framework doesn't exclusively pick/forbid Big5 or CNS, That's *not* what I mean. What I do mean is that Fung is not providing a clear usage model. There are millions of Big5 users out there, and Fung is giving these people mixed signals about how they are to use EHZ. At various times, Fung has said that Big5 users may want to translate Big5 into CNS, or CNS plus GB, or an unspecified mixture of CNS plus GB plus JIS, or they may simply want to use EHZ-Big5, whose design parameters are dictated by a desire to have the same "anchor points" as CNS, for some unspecified reason. I think I am justified in describing these mixed signals as "lack of clarity about CNS versus Big5". > you should read Dr. Fung Fung Lee's messages on this issue. I have read all of Fung's postings with great interest. > (3) Again, as I pointed out before, EHZ provides equal ASCII > transparency (compared to HZ) for all the coding schemes while others, > like HZ+S, don't. In this sense, EHZ is more neutral. (Didn't we spend > a lot of bandwidth on this "policitical" issue of "fairness"?) You spent a lot of bandwidth, but you didn't settle the issue to my satisfaction. The simple fact is that EHZ is far from neutral as between GB and Big5, because EHZ makes GB the default non-ASCII mode. By contrast, HZ+ is neutral in this sense. I think you are giving too much weight to the issue of "maximal ASCII transparency". It is blinding you to other issues that are much more important. -- Steve From handa@etlken.etl.go.jp Fri Jul 8 20:43:54 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA15180; Fri, 8 Jul 94 20:43:54 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA28881; Sat, 9 Jul 94 10:41:35 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA12188; Sat, 9 Jul 94 10:41:35 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA12013; Sat, 9 Jul 94 10:41:41 JST Date: Sat, 9 Jul 94 10:41:41 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407090141.AA12013@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Fri, 8 Jul 1994 16:00:54 -0400 <9407082004.AA02602@sutgate.bitnetjp.ad.jp> Subject: Re: reply to Yuan's points about vendor-specific Big5 Status: O On Fri, 8 Jul 1994 16:00:54 -0400, Stephen G Simpson said: > much better. One reason why HZ+'s Big5 support is much, much better > is that it guarantees 100 percent round-trip accuracy, no matter which > vendor's Big5 extension is being used. CNS translation cannot achieve > anything like this kind of accuracy. My proposals Handa-1 and Handa-2 (previously called as HZ-EA and HZ-EA-2) are to be categolized as "CNS translation" methods, but they also "guarantees 100 percent round-trip accuracy". > Please remember that the goal of HZ+ is to provide a convenient > representation of mixed ASCII, GB, and Big5 text for use on the > Internet. I sincerely believe that HZ+ is the best short-term way to > achieve this goal. If you don't think this is an important goal, then > you have no reason to be interested in HZ+. I think all other proposals also have the same goal. The difference exists in how they grasp the meaning of `convenience'. The convenience of HZ+ is large for soft writers. But for end users, it's not that different from other proposals. In addition, if each proposer provides general subroutines for his proposal which can be easily used by any soft writers, even the superiority of HZ+ for soft writers gets smaller relatively. My post of "HZ-EA encoder/decoder" is a preliminary attempt to provide such subroutines. [If the program didn't reach someone, please mail me. I'll send it by private mail. If many persons request it, I'll post it again to this mailing list.] --- Ken'ichi HANDA handa@etl.go.jp From yawei@cs.indiana.edu Sat Jul 9 00:35:46 1994 Return-Path: Received: from moose.cs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22120; Sat, 9 Jul 94 00:35:46 CDT Message-Id: <9407090535.AA22120@ifcss.org> Received: by moose.cs.indiana.edu (5.65c/9.4jsm) id AA08200; Sat, 9 Jul 1994 00:33:30 -0500 Date: Sat, 9 Jul 1994 00:33:30 -0500 From: "Ya-Gui Wei" To: alt.chinese.computing@usenet.ucs.indiana.edu, soft-authors@ifcss.org Subject: A Script Language for Configurable Decoders Cc: yawei@cs.indiana.edu Status: O The following script language may be used to implement user programmable HZ (or whatever) decoders. Changes since last draft: - removed "rotate" operators. they can be simulated with the shift operators if neccessary. - added "register" operators. - added "static array" operators. - added procedures and recursions. - added i/o operators (optional). We can add more bells and whistles, but I think this is enough for our purpose for now. I am trying to keep it simple enough so that an interpreter could be implemented easily. Z-Script A Simple Stack-Based Programming Language (Draft 1.1) Z-Script is stack-based language with the following specifications. Input and output: Input is 16-bit number as the only element on the stack. Output is 16-bit number(s) left on top of stack. Language syntax: Stack based languages tend to have simple syntax -- a segment of Z-script code is simply a string of unstructured operators and constants. The only chances to get a syntax error is when there is a character that is not a valid operator, or when parenthesis and quotation marks are not ballanced. The Z-script is usually executed through an interpreter. Execution proceeds linearly. When a constant (a number, an array, or a procedure) is encountered, a 16-bit representation of the constant is pushed onto the stack. When an operator is encountered, certain behavior happens as defined for the operator: 0 or more operands are popped off the stack, some calculations performed, and 0 or more results are then pushed back on the stack. The above description implies that operands always preceed their intended operators, and the syntax sometimes appears to be in "post-fix" notation. For example, to take the sum of two numbers, we would use expressions similar to "1,2+". Constants: Numeric constants may be supplied as operands, and will be pushed onto the top of the stack as soon as they are encountered. Constants must be specified in decimal format, and ranged from 0 to 32767. Constants may also be specified using printable ASCII characters. Character constants are converted to numeric constants by the parser and are subject to the same range constraints. Single-byte character constants are converted to their ASCII numeric values. Double-byte character constants are converted to 16-bit numeric constants by placing the ASCII value of the first byte in the highest 8-bit and the second byte in the lowest 8-bit. Character constants must be quoted by single quotes. Examples of character constants: 'a', '~}' etc. The range constraint is to allow the interpreter to store numbers and operators as 16-bit tokens. Implementations using larger tokens may allow constants up to 65535. Intermediate Results: All intermediate results are at least 16-bit, and are usually treated as unsigned numbers. Operators: General arithmetic and logical operators: The following operators uses the top-most two elements from the stack as operands. (Note that the / operator generates two results.) (Wherever "first", "second", "third" are used with operands and results, we refer to the order they were pushed onto the stack, which is opposite from the order they were popped.) + - addition. - - subtract the second operand from the first operand. (Example: "2,1-" results in "1".) * - multiplication (unsigned). / - division (unsigned). divide the first operand with the second operand. After the division, the quotient is first pushed onto the stack, followed by the remainder. (The remainder is on top of the stack.) (Example: "7,3/" results in "2,1".) & - bitwise AND. | - bitwise OR. ^ - bitwise XOR. > - greater than test. if first operand is greater, result is 1 (true). else 0 (false). Operands are treated as unsigned numbers. < - less than test. = - equal test. [ - shift left. second operand is the shift count. ] - shift right. m - merge. The low byte of the first operand is taken as the high byte of the result, and the low byte of the second operand is taken as the low byte of the result. This is identical in effect to "255&w255&8[|". (Example: "1,2m" results in 258.) The following operators take 0 to 3 operands: w - swap the position of the top two elements on the stack. l - split. opposite of "m". (Similar to "256/", but takes less CPU time.)) p - the top element of the stack is popped (discarded). d - the top element of the stack is duplicated. ~ - do a bitwise NOT of the element on top of stack. ? - conditional. takes 3 operands. if the first operand is non-zero, the second operand is the result, otherwise the third operand (top-most) is the result. Portion of the stack may be reserved as special storage space. Such storage space (referred to hereafter as "registers") may be accessed with the following operators. r - Reserve register space. Takes 2 operands, the second operand being the amount of space to reserved, which is added to the stack pointer (recall that both operands have been popped). The first operand is then pushed back onto the new top of the stack. The reserved space is uninitialized. To reserve initialized space, simply push constants. s - Register store. Takes 2 operands. The first operand is the value to store, the second operand is an index pointing to register location. The bottom of the stack being index 0. f - Register fetch. Takes 1 operand, which is the index to the register. The content of the register is pushed onto the top of the stack as result. n - Register increment. Takes 1 operand like 'fetch'. The original content of the register is pushed to the stack, the register itself is THEN incremented by 1. This is a short cut instruction that may be used as loop counter. t - Stack Top. This operator takes no operand and push the number of elements on the stack (not counting result of this operator, but counting reserved register space) onto the top of the stack. Static arrays are storage areas separate from the stack. Arrays are initialized when the script is parsed at load time, and persist between invocations of the script. Each member of an array is a number. The following operators are array-related: () - Specify a static array and the content of each array element. Arrays may NOT be nested. Example: "(1,2,3)" specifies a 3-element array. a - array reference. Takes 2 operands, the first operand being an array subscript (0 based), the second operand being an array. The array element at the subscripted location is returned as result. Example: "2(10,11,12)a" => 12. k - array lookup. Takes 2 operands. The first operand is some value, the second operand is an array. The value is compared with successive elements of the array. Returns the location of the first match. If no match, the returned location points to 1 past the last element of the array. ! - set array element. Takes 3 operands. The first operand is a value, the second operand is an array subscript, the third operand is an array. The operator sets the subscripted array element to the value, and returns no result. No-op if index is out of bounds. Procedures: Procedures are executable arrays, arrays containing operators and operands. Procedures are executed only if given as operand to the 'x' operator. Procedures may be nested. {} - Specify a procedure. For example: "d20>{48+}{10-}?x" either adds 48 or subtract 10 from the input, depending on whether the input is greater than 20. $ - Push current procedure. The currently executing procedure is pushed on the stack (if used outside of a procedure, 0 is pushed.) May be used together with 'x' to implement self- recursion. x - Execute. Takes 1 operand. If the operand is a procedure, its contents are executed. If the operand is 0, it returns without doing anything. All other operands are invalid. The 'x' operator may be used within a procedure to implement recursions. When an 'x' occurs as the last operator in a procedure, it is called tail recursion. Tail recursion is preferable because it doesn't cause growth on the system stack (note that this is seperate from the Z-script stack). Arrays (and procedures, which are a special kind of arrays) are pushed onto the stack as 16-bit tokens when they are encountered. They may serve as operands to the swap (w), pop (p), duplicate (d) and conditional (?) operators, in addition to the operators specifically designed for them. I/O operators: A language is not complete without I/O operators. So here they are: i - Takes no operands. Read one character from the standard input and push it onto the stack. Return 0xFFFF if EOF. o - Takes 1 operand, the ASCII value of a single character, which is sent to the standard output. Returns no result. Implementation of I/O operators is optional. They may be omitted in situations where Z-script is called as subroutines from another language which handles the actual I/O. The following symbols are used but are not operators: , - comma may be used to seperate operands/operators whenever ambiquities may occur. e.g. "127,127m". \ - continuation on next non-space character. Intervening space, tab and newline characters are ignored. # - comments until end of line. "" - the entire script string may be enclosed in quotes. Error Conditions: If an error occurs, execution is terminated prematurely, stack pointer is reset to 0, and -1 is pushed on the top of the stack. The following are the list of error conditions: Stack underflow. Stack overflow. Division by zero. Operand to "x" is invalid. Index operand to array operators is out of range. Array operator to "!" is invalid. Excercises and Examples: Ex1. Why do the following work? A. Convert GB to HZ: "32639&" B. Convert HZ to GB: "32639~|" C. Convert GB or HZ to dictionary offset: "32639&8481-lw94*+" D. Convert dictionary offset to HZ: "94/33+w33+wm" E. Convert Big5 to HZ-2 (Block 1): "dlw161-wm7]33+w127&m" F. Convert HZ-2 (Block 1) to Big5: "d33-1]161+wlw33-1&7[|m" G. Convert Big5 to HZ-S (Block 1): "ld128&98,64?-w161-157*+94/33+w33+wm" H. Convert HZ-S (Block 1) to Big5: "l33-w33-94*+157/d62>98,64?+w161+wm" Ex2. Examine the following script which converts HZ-Big5 (HZ+S) block 2 characters to native Big5. "'!!'-lw94*+6280+157/d62>98,64?+w161+wm" Let's see: '!!'- # subtract '!' from both bytes of input lw # split input into two, and swap first byte to top 94*+ # multiply first byte with 94, then add to second byte 6280+ # shift to Block 2 (block 2 start at offset 6280) 157/ # divide by 157 (Big5 row size), remainder on top d62> # duplicate remainder, compare copy to 62 98,64?+ # add 98 or 64 to remainder, depend on whether it's > 62 w161+ # swap quotient to top, and add 161 to it wm # swap remainder to top again, and merge into 16bit output. Drawing a stack on a piece of paper and see how things go in and out of stack during the above steps would help. Ex3. Use Z-script to implement a decoder for extended HZ as follows: Starting at the beginning of a text line, the decoder is called with first 2 characters as input. The decoder returns 3 fields on top of stack as follows: 1st field tells the caller how many characters have been processed. If both characters have been processed, the next call will be for the next two characters. If only 1 character has been processed, the 1st character of the next called will be the same as the 2nd character of the current call. The field value of 1 also tells the caller to output the first character as ASCII. If the field value is 2, output depends on the next two fields. 2nd field: If 0, the two character being processed is an HZ escape sequences. If none-zero, this field contains the escape sequence that initiated the current context. 3nd field contains the current character in decoded form. Let's see: "(0, 0, 0)w # static storage in reg 0, first elem is state flag, # second escape-num, third is escape-sequence; ('~{','~<')w # list of escape-in sequences in reg 1; (0, 0, 0)w # array of procedures in reg 2; Note that we can't # initialized arrays with procs directly; {32639~|} 0 2f! # init HZ-GB decoder in proc array {'!!'-lw94*+157/d62>98,64?+w161+wm} 1 2f! # init HZ-Big5 Blk1 decoder in proc array 0 0fa 0= # current state is zero? { # state 0 procedure (ASCII context) d 1f k # compare input with escape-in sequences. d 1 0f! # store comparison result in escape-num 298,64?+w161+wm} 1,2f! \ 0,0fa0= {d1fkd1,0f!3w127<&w0?" C. "p(0)d0wa1+d13940 Received: from moose.cs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22244; Sat, 9 Jul 94 00:37:37 CDT Message-Id: <9407090537.AA22244@ifcss.org> Received: by moose.cs.indiana.edu (5.65c/9.4jsm) id AA08294; Sat, 9 Jul 1994 00:35:21 -0500 Date: Sat, 9 Jul 1994 00:35:21 -0500 From: "Ya-Gui Wei" To: alt.chinese.computing@usenet.ucs.indiana.edu, soft-authors@ifcss.org Subject: Consolidated Coding Standards, Revision 1 Cc: yawei@cs.indiana.edu Status: O A Proposal for a Consolidated Collection of East Asian Language Coding Standards Using Solely ASCII Printable Characters (Revision 1) Ya-Gui Wei First Draft Release April 07, 1993 Revision 1 Release July 9, 1994 (C) Copyright Ya-Gui Wei. Faithful reproduction, transcription, transmission, and transliteration are explicitly permitted. The "HZ" representation (Fung Fung Lee, 1989) of GB2312 Chinese text has been implemented in various software packages under different platforms, and tested in the usenet newsgroup "alt.chinese.text" and various other forums with considerable success. This proposal seeks to expand the specification to _simultaneously_ accommodate other East Asian coding standards under an umbrella scheme that is analogous to the original "HZ" scheme. * ESSENSE of "HZ" The "HZ" standard defines a way of integrating ASCII characters with GB2312 Chinese characters using solely 7-bit ASCII printable symbols. The following ASCII sequences are defined as special in HZ text: ~{ -- escape from ASCII context to GB2312 ~} -- escape from GB2312 context to ASCII ~~ -- the ASCII character ~ ~\n -- line continuation "HZ" further stipulates that each line must start in the ASCII context. Furthermore, the ~\n line continuation sequence is permitted in the ASCII context only. * CONSOLIDATION OF CODES I hereby propose to extend the "HZ" specification to create a Consolidated Collection of East Asian Coding Standards (hereafter, CCEACODE, pronounced as "see code"), to allow for the simultaneous transport of text of the different languages or coding standards. Briefly, all the remaining tilde- sequences of "HZ" will be defined as special under CCEACODE, which will be used as escape signals for transition among East Asian Language (EAL, hereafter) code blocks, as well as between EAL code blocks and ASCII. Code Blocks of 93 rows-by-94 columns will be defined by CCEACODE, with each character within an code block represented by two printable ASCII characters. If two consecutive characters are from the same code block, no special attention is needed. If two adjacent characters are from different code blocks, a special tilde- sequence is inserted in between to signal the transition between code blocks. For example, if ~{ is used for transition into GB (Chinese) text, and ~[ is used for transition into JIS (Japanese) text, and ~} is used for transition into ASCII text, then examples of mixed ASCII, GB and JIS text may look like: aaaa~{gbgbgbgb~[jijijiji~}aaaa aaaa~[jijijiji~{gbgbgbgb~}aaaa * RATIONALE The HZ specification, and this extension, are designed with two things in perspective: the need to transmit mixed lingual text through ASCII oriented 7-bit channels, and the need to process such text with ASCII oriented software. These are the basic rationale behind keeping all text and escape sequences within the range of ASCII printable characters. The approach of using escape sequences to perform context switching is validated by the following observations: a text string of consecutive characters are more likely than not from the same language, and therefore, the same character set; and in languages with large character sets, the character sets are frequently organized into segmented planes sorted by usage frequency. These all contribute to the space efficiency of the context switching approach. * PROPERTIES - Large Code Space. CCEACODE can accommodate 92 code blocks, with each block having 93 rows, and each row having 94 characters. This results in a code space of up to 804,000 characters, or 19.6 bit equivalence, while each character takes up only about 14 bits in the data stream. (Contrast this to 16-bit schemes, which would have a mere 65,000 character code space, with each character taking up 16 bits in the data stream.) - CCEACODE will be a superset of ASCII. Under CCEACODE, ASCII text will remain as 7-bit (single-byte) characters, with no need to widen them into multiple byte sequences. The only exception being that an ASCII "~" character will be represented by the two byte "~~" sequence. (Contrast this to 16-bit uniform width schemes, which would widen each ASCII character to 16 bits -- requiring all existing software to be re-written.) - CCEACODE will be a superset or partial superset of all the East Asian coding standards it seeks to accommodate. - CCEACODE will be a superset of the original "HZ" Specification. - CCEACODE encoded multilingual text will be indistinguishable from ASCII text at the byte level, thus ensuring compatibility with existing software and hardware. Contrast this with ISO-2022, which uses non-printable character in the escape sequence. - The boundaries of each character in CCEACODE encoded text will co-incide with byte boundaries. This will facilitate the implementation of decoders, especially the class of _in situ_ decoders inspired by the original HZ specification, which perform decoding in the device output stream, allowing ASCII-oriented software to manipulate HZ text without modification. Contrast this to the various schemes for converting binary data to 7-bit representations that do not respect original character boundaries, such as UTF-7, uuencode, btoa, etc. * CONTEXTS A piece of CCEACODE encoded text can be divided into "Contexts", or clusters of characters belonging to the same character set. A cluster of ASCII text can be called the ASCII context, a cluster of GB Chinese can be called the GB context, etc. A context consisting of single byte characters (e.g. ASCII) is called a single-byte context, a context consisting of double byte characters is called a double-byte context. CCEACODE uses explicit escape sequences to switch between contexts. All context switching escape sequences are two bytes in length, and the first byte is always the tilde character (~). The new line sequence shall occur only within the ASCII context. All escape sequences occuring within a two-byte context must be properly aligned, such that the first byte of the escape sequence co-incides with the first byte of the two byte character that would have existed in that position. Improperly aligned escape sequences in a two-byte context will not be interpreted as escape sequences, but rather, will be regarded as components of the two-byte characters. * SUPPORTED CHARACTER SETS CCEACODE does not attempt to define any of the characters within its code space. Instead, its code space will be allocated to the various official or _de facto_ coding standards in blocks, and individual characters will be defined by these official or _de facto_ coding standards. CCEACODE will also standardize the tilde- escape sequences and the exact positioning of standard character sets within the CCEACODE code space. Code Blocks, each 93x94 in size, are allocated to accommodated coding standards. A special tilde- escape sequence is assigned to each code block. Proposed CCEACODE tilde- special sequence assignments: ~} -- escape to ASCII (from a HZ context) ~{ -- escape to Chinese (GB-2312) ~] -- escape to Korean (KSC-5601) ~[ -- escape to JIS-X0208 ~< -- escape to Chinese Big5 Block 1 ~> -- escape to Chinese Big5 Block 2 ~@ -- escape to CNS-11643 Level 1 ~# -- escape to CNS-11643 Level 2 ~A-~J -- reserved for Unicode ~~ -- the ASCII character ~ ~\n -- line continuation (in ASCII context only) (\n = new line sequence, may be platform-specific.) All other undefined escape sequences are reserved for future expansion. * REPRESENTATION OF CHARACTERS Each character in the supported character sets will be represented by two printable ASCII characters within the assigned code block. Character sets in the GB, CNS, JIS and KSC series which are defined as 94x94 arrays will be represented as ASCII characters by shifting the array indices into printable ASCII range (by adding 33). The first ASCII character represents the row number and the second ASCII character represents the column number. Since each CCEACODE code blocks are only 93x94 in size, the last row of the 94x94 arrays must be undefined. Characters defined outside of the 93x94 range must be assigned to separate code blocks. The Big-5 character set will be represented as follows: - The first 5872 characters (including 471 symbols), will be refered to as Big-5 Block 1, and the 7632 infrequently used characters as Big-5 Block 2. The two blocks will be assigned seperate CCEACODE code blocks. - Within each block, each character is first assigned a linear index number consecutively according to their original order within the Big-5 table, and then arranged into 94x94 arrays by assigning the first 94 characters into row 0, the next 94 characters into row 1, etc. - Further steps proceed as other 94x94 character sets. CCEACODE representation of Unicode characters will be defined in a future revision of this document. * USER DEFINED CHARACTERS Characters not officially documented in the official character sets, or are different between vender applications in the _de facto_ standard character sets, are considered User Defined Characters. User Defined Characters should not occupy space within Code Blocks assigned to the individual character sets, even if the space is unused by the assigned character sets. Two escape sequences will be reserved for use with user defined characters and related font information: ~_ -- escape to user defined block (UDB) ~= -- escape to NETFONT information NETFONT is a protocol designed to transport bitmap font description for characters defined in the CCEACODE framework. Its syntax will be illustrated with an example: ~=p~[cc0000000000000000000000000000000000000000000000000000000000000000~} Explanations: ~= Escape sequence. Indicate the start of NETFONT information, which carries font description for one CCEACODE character. p Flag bytes. A "p" (persistence) indicates that the font information should be kept in persistent storage because the bitmap belongs to some standard character set. Absense of "p" indicates that it's something made up by the author arbitrarily for one-time use only. Other flags may be defined in the future. ~[ Character set. The CCEACODE escape sequence for the character. cc The character in its CCEACODE rendition. 0.. This is the 16x16 bitmap information coded in hexadecimal numbers. Every 4 digits specify a scan line, the pixels to the left comes first. Within each digit, the highest bit represent the left-most pixel. In this example, a blank is specified. ~} escape back to ASCII context, end of NETFONT information. Appendix I contains a suggestion on the implementation of the persistent storage used for NETFONT data. * FUTURE ASSIGNMENT OF ESCAPE SEQUENCES To minimize accidental collision with application-specific sequences when a user inadverdently applies a non-CCEACODE document for CCEACODE decoding, escape sequences will be assigned according to the following schedule: Group 1: ~{}[]_@<=>#$%&()*+/ Group 2: ABCDEFGHIJKLMNOPQRSTUVWXYZ Group 3: abcdefghijklmnopqrstuvwxyz Group 4: 1234567890 Group 5: "',.;\^`- Group 6: !:?| * NAME OF THE GAME This proposed specification should be referred to as "Consolidated Collection of East Asian Coding Standards", with acronym CCEACODE (pronounced "see code"). Mixed-language text encoded under the CCEACODE framework may continue to be referred to as "HZ text". Implementation of individual coding standards under CCEACODE may be referred to by adding an HZ- prefix to the standard, such as HZ-GB2312, HZ-Big5, etc. * ACKNOWLEDGEMENT I would like to thank the following individuals: Ed Lai for promoting the use of 7-bit Chinese encoding on usenet and co-authoring the 'zW' protocol with me; Chunqing Cheng for proposing the use of ~{ and ~} escape sequences to mix 7-bit Chinese characters with ASCII; Fung Fung Lee for writing and implementing the original HZ protocol from which the current extension is based; L.S. Ng for proposing a skeletal scheme which evolved into the NETFONT protocol used in this document; Ken'ichi Handa for using the 7-bit rendition of Big-5 in Mule and Steve Simpson for energetically promoting it as an HZ extension. + + + Appendix I: Implementation Of Persistent NETFONT Storage Persistent storage of NETFONT bitmap may be implemented using an extensible hash table. 1. Hash function The recommended hash function is the exclusive OR of the two bytes of the character as well as the second byte of the escape sequence: hash_val = esc_char XOR byte1 XOR byte2; 2. Each hash_entry (also called a "bucket") in the hash table is a structure: struct hash_entry { int local_hash_depth; struct char_entry[n]; }; In addition, a header structure for the table is also defined: struct hash_header { int global_hash_depth; char global_hash_mask; int chars_per_bucket; }; The total number of hash_entry in the hash table is 2^d, where d = global_hash_depth. The maximum usable depth equals to the number of bits in the output of the hash function (8 if the recommended hash function is used). The hash_mask's are functions of hash_depth's: hash_mask = (2^hash_depth) - 1. 3. Each hash_entry (bucket) may have some number (n) of entries defined as follows, where the value of n is implementation defined. Each entry contains the storage information of one NETFONT character. struct char_entry { char hash_val; char escape_char; char byte1; char byte2; loc_t location; }; where "location" may refer to the position in a file where the actual bitmap of the character is stored. (Storing the bitmap within the hash table is not space efficient.) To search for a character within the hash table, first find the bucket number containing the character entry. The bucket number is computed by AND'ing the hash_val with global_hash_mask: bucket_num = hash_val AND global_hash_mask then search through the bucket for an character entry with an exact match in hash_val. If the hash_val's match, make sure the escape characters and the characters themselves match as well. To insert a character into the table, find the bucket, then search for an unused char_entry. A NULL value in the escape_char field may be used to indicate unused entries. 4. Splitting. If any hash_entry (bucket) becomes full, the bucket must be splitted, and the hash table may need to be extended. The procedure for splitting is as follows. If the local_hash_depth is less than global_hash_depth, then just do (1) set local_hash_depth to global_hash_depth; (2) delete any character entries that no longer belong to the bucket, i.e., if (hash_val AND global_hash_mask) does not equal to bucket_index. If the local_hash_depth in the full bucket equals to the global_hash_depth, extend the table by (1) replicate the entire hash table once, placing the second copy immediately after the first copy; (2) increment global_hash_depth; (3) recalculate global_hask_mask. Why would local_hash_depth not equal global_hash_depth? This is because when we replicate the hash table, we do not go through the entire table to split individual buckets. Splitting all the buckets in one operation would take too long and degrades perceptive performance on an interactive system. 5. Overflow. The hash table usually starts out with 1 bucket, and can grow to as many as 256 buckets. If a bucket becomes full when the 256 bucket limit is reached, an overflow occurs. An overflow hash table is indication that the originally chosen bucket size (number of char_entries in each hash_entry) is too small. An overflow can be fixed by physically enlarging the size of each bucket (a somewhat expensive process), and can be prevented by selecting a more reasonable bucket size in the first place. [END] From yawei@cs.indiana.edu Sat Jul 9 23:49:10 1994 Return-Path: Received: from moose.cs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer) id AA18700; Sat, 9 Jul 94 23:49:10 CDT Message-Id: <9407100449.AA18700@ifcss.org> Received: by moose.cs.indiana.edu (5.65c/9.4jsm) id AA26846; Sat, 9 Jul 1994 23:46:55 -0500 Date: Sat, 9 Jul 1994 23:46:55 -0500 From: "Ya-Gui Wei" To: alt.chinese.computing@usenet.ucs.indiana.edu, soft-authors@ifcss.org, yawei@cs.indiana.edu Subject: Re: A Script Language for Configurable Decoders Status: O Following is a Z-script program that does HZ-GB, HZ-Big5(HZ+S), and HZ-JIS decoding. "(0,0,0,0) ('~{','~[','~<','~>') (0,0,0,0,0) {32639~|} d0,2f! 1,2f! {'!!'-lw94*+157/d62>98,64?+w161+wm} 2,2f! {'!!'-lw94*+6280+157/d62>98,64?+w161+wm} 3,2f! {0,0fa0= {0w0w 1fkd 1,0f!4 Message-Id: <9407110149.AA12366@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: John Delacour's message of Wed, 6 Jul 1994 18:57:41 +0100 <9407062037.AA22372@sutgate.bitnetjp.ad.jp> Subject: Re: Moving the Goalposts (was "A compromise proposal") Status: O On Wed, 6 Jul 1994 18:57:41 +0100, John Delacour said: > The attraction of Unicode is undeniable and we all wish very much for its > adoption in many environments, I'm sure. The question at the moment is > whether, for the foreseeable future and for for present purposes, it is the > best solution to the problem of encoding Chinese (whether Big-5, CNS or > GB). In the long run the Han Unification of ISO 10646 (=Unicode) is > obviously the answer. I'm quite doubtful about the merit of ISO10646, or at least, about the merit of Unicode. Unicode limits the number of characters to 2^16. Is it really enough for a long term? For instance, how it deals with CNS's Plane 3 and over? I heard that there already exist CNS Plane 1-8, and the original plan of CNS contains Plane 1-14 (or 16?). There still left some space for CJK in Unicode, but it can't cover them all. Instead, ISO10646 has powerful extensiblity using 32 bits. But, current approvers of ISO10646 seems to be ignoring this extensiblity. Unicode is the only one plane (PLANE0) of one group (GROUP0). If another planes or another groups are defined, full support of ISO10646 is quite a heavy load. One more point I don't like about ISO10646 is that it doesn't give any language tags. Considering multilingual applicationss, we definitely have to distinguish two same-looking characters of Chinese and Japanese. Once those are unified into one code without any language tags, the information of where the character originally comes from is lost forever. --- Ken'ichi HANDA handa@etl.go.jp From nsysu11@cc.nsysu.edu.tw Mon Jul 11 00:28:49 1994 Return-Path: Received: from cc.nsysu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA29770; Mon, 11 Jul 94 00:28:49 CDT Received: (from nsysu11@localhost) by cc.nsysu.edu.tw (8.6.9/8.6.9) id NAA03981; Mon, 11 Jul 1994 13:21:43 +0800 Date: Mon, 11 Jul 1994 13:09:52 +0800 (CST) From: uu Subject: subscribe To: emx-list@eb.ele.tue.nl, emtex-user@chemie.fu-berlin.de, unicode@unicode.org, soft-authors@ifcss.org, mule@etl.go.jp Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Due to an error I lost all my mailing list maintainer addresses, and I apologize for contaminating these lists... I'm now in Taiwan and don't want to make TTTeeelllnnneeettt tttooo Aaauuussstttrrriiiaaa :-) Please suscribe me to this list, and send me the mailing addresses of the list maintainers. Thank you in advance Werner Lemberg From Ricky.Yeung@Eng.Sun.COM Mon Jul 11 01:54:51 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA01883; Mon, 11 Jul 94 01:54:51 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03916; Sun, 10 Jul 94 23:52:23 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07761; Sun, 10 Jul 94 23:54:14 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA14350; Sun, 10 Jul 1994 23:53:31 +0800 Date: Sun, 10 Jul 1994 23:53:31 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407110653.AA14350@hk.Eng.Sun.COM> To: soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Fri, 8 Jul 1994 18:27:09 -0400 <199407082227.SAA07083@boole.math.psu.edu> Subject: Getting the record straight (Was Re: reply to Ricky's criticisms) Content-Length: 5760 Status: O > From: Stephen G Simpson > Date: Fri, 8 Jul 1994 18:27:09 -0400 > > I find your tone rather abrasive. I'm trying to hold my temper here. > You did not settle anything long ago. On June 9, Simpson wrote: ++ My view is that your suggestions make a lot of technical ++ sense, but politically I'm wondering whether they are a good idea. ++ Politically, I think it is a little late in the game to be making And Yeung replied: == Ok, now we're settled on the technical front. Let's talk about == politics. No objection was raised against this statement. After I proposed the Extended HZ framework, on June 13, Simpson wrote: ++ This framework looks good. I am thinking that maybe I will change ++ HZ+S to conform to Ricky's framework. I'm thinking of using ~0, ~1, ++ and ~2 as the escape sequences for Big5. (~1 and ~2 for ETen Big5 ++ blocks 1 and 2, ~0 for the ETen user-defined area as pointed out by ++ Sandstrom. Note that this choice of escapes is in a sense ISO 2022 ++ compliant, since 0, 1, 2, ... are reserved as ISO 2022 final ++ characters for application-specific character sets.) I'll let the readers be the judge on Simpson's statement: "You did not settle anything long ago." (Maybe I should say NOT long ago instead. :-) > I don't have any misconceptions whatsoever. As for Simpson's misconception of the redundancy of "~{" and "~A" in my proposal, in my June 9 reply, I wrote: == No, you're wrong. Every time you hit ~{ you switch to non-ASCII mode, == not GB mode, only when the following character is not ~, then you're in == GB mode. If your parser switches to GB whenever you see ~{, then it's == semantically wrong (according to my proposal). > HZ and HZ+ use ~{ to switch into GB mode. EHZ uses both ~{ and ~A in > different contexts for the same purpose. Even though there may be a > subtle distinction in your mind, it is still very clear that ~{ plus > ~A is more complicated by a factor of 2 than ~{ alone. You can't deny > this. Similar remarks apply to HZ+'s ~> versus EHZ's ~{~g. > What I am pointing out is that EHZ's escape sequences are more > complicated than HZ+'s. This is obviously the case, and for you to > try to deny it is silly and pointless. If you want to argue that the > extra complication buy us some advantage (e.g. "maximal ASCII > transparency"), I'll listen and decide for myself. But please don't > try to deny the obvious. On my first post on the ASCII transparency issue, I explicitly stated that the only drawback for my proposal is two extra bytes per switching into non-ASCII mode. I think your use of the term "silly and pointless" is really silly and pointless. > > (or ~1, BTW, which escape sequence are you going to stick to? They > > seem to be switching constantly). > > I think I'll stick to ~>. I don't know why you say they are switching > constantly. The HZ+ escape sequences changed only once, in response > to a criticism having to do with C programs. Again, I find your tone > rather abrasive. In your reply to my proposal above, you seemed to decide to use ~0/~1/~2. During the e-mail exchange a month ago, they seemed to be used interchangeably. > > (2) If your "lack of clarity about CNS versus Big5" means that the EHZ > > framework doesn't exclusively pick/forbid Big5 or CNS, > > That's *not* what I mean. What I do mean is that Fung is not > providing a clear usage model. There are millions of Big5 users out > there, and Fung is giving these people mixed signals about how they > are to use EHZ. At various times, Fung has said that Big5 users may > want to translate Big5 into CNS, or CNS plus GB, or an unspecified > mixture of CNS plus GB plus JIS, or they may simply want to use > EHZ-Big5, whose design parameters are dictated by a desire to have the > same "anchor points" as CNS, for some unspecified reason. I think I > am justified in describing these mixed signals as "lack of clarity > about CNS versus Big5". I think your statement on EHZ: "lack of clarity about CNS versus Big5" seems to be "lack of clarity." The framework is pretty clear that both Big5 and CNS are not excluded. How the user uses a particular mapping is a different issue. I'll leave it to Fung Fung Lee to answer this. > > you should read Dr. Fung Fung Lee's messages on this issue. > > I have read all of Fung's postings with great interest. > > > (3) Again, as I pointed out before, EHZ provides equal ASCII > > transparency (compared to HZ) for all the coding schemes while others, > > like HZ+S, don't. In this sense, EHZ is more neutral. (Didn't we spend > > a lot of bandwidth on this "policitical" issue of "fairness"?) > > You spent a lot of bandwidth, but you didn't settle the issue to my > satisfaction. The simple fact is that EHZ is far from neutral as Excuse me. It's not been my goal to settle EHZ issues to YOUR satisfaction. BTW, I'll refer the readers to the quotes at the beginning of this message on how satisfy Simpson was or wasn't on my proposal. :-) > between GB and Big5, because EHZ makes GB the default non-ASCII mode. > By contrast, HZ+ is neutral in this sense. EHZ is far more neutral than HZ+S on the issue of ASCII transparency. BTW, choosing GB as the default is ONLY for backward compatibility with HZ. > I think you are giving too much weight to the issue of "maximal ASCII > transparency". It is blinding you to other issues that are much more > important. What other much more important issues are you referring to? -Ricky From handa@etlken.etl.go.jp Mon Jul 11 05:59:03 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA07601; Mon, 11 Jul 94 05:59:03 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA12622; Mon, 11 Jul 94 19:56:20 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA02074; Mon, 11 Jul 94 19:56:19 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA12660; Mon, 11 Jul 94 19:56:25 JST Date: Mon, 11 Jul 94 19:56:25 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407111056.AA12660@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Ross Paterson's message of Mon, 11 Jul 1994 10:42:00 BST <9407110949.AA27634@sutgate.bitnetjp.ad.jp> Subject: Re: ISO-10646/Unicode (was: Goalposts, compromises) Status: O On Mon, 11 Jul 1994 10:42:00 BST, Ross Paterson said: > Since Unicode (= the UCS-2 form of ISO 10646) includes all the characters > of GB2312, Big5, JIS X208 and JIS X212, it would seem to cover most > people's needs. If some specialized groups want an larger hanzi/kanji set > (as will doubtless appear in the UCS-4 form), they will have to accept > a heavier load, no matter what encoding they use. In most implementation > schemes for Unicode/ISO 10646, you only pay for what you use. Once a soft is created in a way that it only handles UCS-2, it seems to be very difficult to modify it later for larger character sets. This is just the same as Big5 (or GB-EUC, JIS-EUC) oriented soft can hardly be extended so that it can handle another character sets. Instead, if a soft is created, from the start, by considering extensibility, adding support for another character set is not that difficult. The same thing can be said for extending HZ. Something like `EHZ framework' can easily be extended, but, if we adopt Unicode base approach, we lose the extensibility. And to implement Unicode base approach without loosing extensibility results in loosing simpleness. `EHZ framework' doesn't request a heavier load to exchange, for intance, CNS Plane 8. > The usual answer to this is that language tags belong to a different > protocol. That's what happens with ISO Latin-1, where no distinction > is made between English, German, Spanish or a dozen other languages, > or Cyrillic codes covering Russian, Bulgarian, etc, or Arabic codes > covering Arabic, Persian, Uighur, etc. Why won't that work just as well > for Chinese, Japanese and Korean? That's simply because we don't have truely multilingual system yet. For instance, with mule, we can now easily write a dictionary-looking-up application which can automatically select a correct dictionary among Chinese, Japanese, and Korean by using info of character set. But, for European text, we can't get such info (except for Greek and Cyrillic, they are using different character set). I think ISO Latin-1 gives a convenience at the sacrifice of possibility of more sophisticated application. In addition, the convenience can be achieved by an effort of soft even if, for instance, French people decide not to use Latin-1 but their own character set. Another possibility is highlighting text of Japanese and Chinese in diffrent ways. Such a simple thing can't be done if we adopt Unicode. > Even now people are using local codes > to represent foreign languages (e.g. Japanese sinologists using JIS, > or Japanese speakers in Taiwan using Big5). And they surely have inconvenience because they can't apply any Japanese softwares for their pseudo Japanese text (in the case of Big5 users). --- Ken'ichi HANDA handa@etl.go.jp From simpson@math.psu.edu Mon Jul 11 10:11:49 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA15417; Mon, 11 Jul 94 10:11:49 CDT Received: from leibniz.math.psu.edu by cnd.org (4.1/4.7) id AA10239; Mon, 11 Jul 94 08:09:56 PDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA03209; Mon, 11 Jul 1994 11:08:09 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Mon, 11 Jul 1994 11:08:07 -0400 Date: Mon, 11 Jul 1994 11:08:07 -0400 Message-Id: <199407111508.LAA14956@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Consolidated Coding Standards, Revision 1 In-Reply-To: <9407090537.AA22244@ifcss.org> References: <9407090537.AA22244@ifcss.org> Reply-To: simpson@math.psu.edu Status: O Ya-Gui Wei writes: > A Proposal for a Consolidated Collection of East Asian > Language Coding Standards Using Solely ASCII Printable Characters > (Revision 1) > ... > ~< -- escape to Chinese Big5 Block 1 > ~> -- escape to Chinese Big5 Block 2 Is this intentional? This is the opposite of HZ+. In HZ+, ~> is used for block 1 and ~< is used for block 2. (My idea is that > stands for "more" and < stands for "less", suggesting blocks containing the more and less frequently used characters.) I mention this in case you want your new proposal to be compatible with HZ+. -- Steve From handa@etlken.etl.go.jp Mon Jul 11 20:43:27 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA10945; Mon, 11 Jul 94 20:43:27 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA17874; Tue, 12 Jul 94 10:40:59 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA07294; Tue, 12 Jul 94 10:40:58 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA13128; Tue, 12 Jul 94 10:41:04 JST Date: Tue, 12 Jul 94 10:41:04 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407120141.AA13128@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Ross Paterson's message of Mon, 11 Jul 1994 14:15:00 BST <9407111319.AA29982@sutgate.bitnetjp.ad.jp> Subject: Re: ISO-10646/Unicode Status: O > Kenichi Handa writes: >> handle another character sets. Instead, if a soft is >> created, from the start, by considering extensibility, >> adding support for another character set is not that >> difficult. On Mon, 11 Jul 1994 14:15:00 BST, Ross Paterson said: > Some people think that having lots of character sets is undesirable. If those are necessary character sets, I think, we should have them. And what is a necessary character set can't be foreseen. So, we need extensibility. > The aim of ISO 10646 is to have only two: UCS-2 and UCS-4, with UCS-2 > a subset of UCS-4. (And UCS-2 covers very character set in wide use > today.) If developers bear that in mind (basically, treat the Char > type abstractly) they will have extensible software. Moreover, the > byte encodings of ISO 10646 (like UTF-8) look the same for either UCS-2 > or UCS-4. Hmmm, on this point, I agree with you. > if one wants to see Cantonese pronunciations? Perhaps the choice > of character set is not the best way to indicate language distinctions. Right, but still better than nothing. Until we build some mechanism of embedding language tag in a text, I don't want to shift to Unicode and loose the current information. I think language tag is not a `rich attribute' like underline, color, or font of `rich text' but a basic element of plane text, because we surely have, in mind, a language tag while writing any text. --- Ken'ichi HANDA handa@etl.go.jp From simpson@math.psu.edu Tue Jul 12 10:51:20 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA04994; Tue, 12 Jul 94 10:51:20 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA11856; Tue, 12 Jul 1994 11:48:50 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 12 Jul 1994 11:48:48 -0400 Date: Tue, 12 Jul 1994 11:48:48 -0400 Message-Id: <199407121548.LAA16728@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: reply to Kenichi Handa's points about HZ+ In-Reply-To: <199407090142.VAA17718@leibniz.math.psu.edu> References: <9407082004.AA02602@sutgate.bitnetjp.ad.jp> <199407090142.VAA17718@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O I wrote: > > .... One reason why HZ+'s Big5 support is much, much better > > is that it guarantees 100 percent round-trip accuracy, no matter which > > vendor's Big5 extension is being used. CNS translation cannot achieve > > anything like this kind of accuracy. Kenichi Handa replied: > My proposals Handa-1 and Handa-2 (previously called as HZ-EA > and HZ-EA-2) are to be categolized as "CNS translation" > methods, but they also "guarantees 100 percent round-trip > accuracy". I don't think so. I'm willing to believe that your translation is 99.9 percent accurate when restricted to the 13053 common Big5 characters and the 406 common symbols. And it may also be fairly accurate for ETen-specific extensions. But your translation cannot be accurate for vendor-specific extensions other than ETen. For instance, a lot of people are using KC, and your translation breaks down for KC-specific extensions. In addition, there is always the possibility that some people may use translations other than yours, and this will introduce additional complications and inaccuracies. I wrote: > > Please remember that the goal of HZ+ is to provide a convenient > > representation of mixed ASCII, GB, and Big5 text for use on the > > Internet. I sincerely believe that HZ+ is the best short-term way to > > achieve this goal. If you don't think this is an important goal, then > > you have no reason to be interested in HZ+. Kenichi replied: > I think all other proposals also have the same goal. I don't think so. HZ+ focuses on 7-bit Chinese by supporting the two most popular Chinese character coding schemes, GB and Big5. Other proposals are focused on other goals: multilingual extensibility, "maximal ASCII transparency", efficiency of mapping schemes, CNS support (odd, because there don't seem to be any CNS users), etc. etc. > The > difference exists in how they grasp the meaning of > `convenience'. There may also be differences in how they grasp the meaning of `Big5'. For example, my understanding of Big5 is quite different from your understanding of Big5. I view Big5 as a popular Chinese coding standard, while you view it as a method for partially encoding other coding systems (some popular, some not) such as CNS, JIS, GB, and ASCII. > The convenience of HZ+ is large for soft > writers. But for end users, it's not that different from > other proposals. I agree that HZ+ is much more convenient for software writers than other proposals. However, I also think that HZ+ is much more convenient for users. As an example, consider Big5 users who want to communicate over channels which are not 8-bit clean. By using HZ+, these users will need only their normal Big5 software plus very simple Big5<->HZ+ filters. They will not need multilingual software supporting CNS, GB, and JIS as would be required by Handa-*, EHZ-*, etc. An additional advantage for HZ+ users is that they will not experience any information loss due to CNS translation. -- Steve From simpson@math.psu.edu Tue Jul 12 11:03:49 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA05526; Tue, 12 Jul 94 11:03:49 CDT Received: from leibniz.math.psu.edu by cnd.org (4.1/4.7) id AA14160; Tue, 12 Jul 94 08:02:07 PDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id KAA11498; Tue, 12 Jul 1994 10:59:06 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 12 Jul 1994 10:59:04 -0400 Date: Tue, 12 Jul 1994 10:59:04 -0400 Message-Id: <199407121459.KAA16671@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: A compromise proposal In-Reply-To: <199407071159.HAA29330@leibniz.math.psu.edu> References: <9407060546.AA17722@simd.stanford.edu> <199407071159.HAA29330@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Kenichi Handa writes: > ... from my point of view, Big5 should be > regarded as not a character set but as an encoding methods > of (part of) several character sets (including ASCII). I don't think many Big5 users would agree with you. Millions of Big5 users would almost certainly *not* want to regard Big5 as an encoding method for CNS+JIS+...+ASCII. Probably most of them have never even heard of CNS and JIS. Rather, they regard Big5 as an independent, popular coding standard, one that they use every day and which is well supported by popular software such as ETen, Chinese Windows, Chinese Macintosh, etc. In designing an exchange standard for Chinese on the Internet, I think we should take the viewpoint of the users into account. If you deny Big5 its identity, you will almost certainly overlook the needs of Big5 users. -- Steve From simpson@math.psu.edu Tue Jul 12 15:24:13 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA15747; Tue, 12 Jul 94 15:24:13 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id QAA13828; Tue, 12 Jul 1994 16:19:24 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 12 Jul 1994 16:19:22 -0400 Date: Tue, 12 Jul 1994 16:19:22 -0400 Message-Id: <199407122019.QAA17061@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Getting the record straight (Was Re: reply to Ricky's criticisms) In-Reply-To: <9407110653.AA14350@hk.Eng.Sun.COM> References: <199407082227.SAA07083@boole.math.psu.edu> <9407110653.AA14350@hk.Eng.Sun.COM> Reply-To: simpson@math.psu.edu Status: O Ricky Yeung writes: > == Ok, now we're settled on the technical front. Let's talk about > == politics. > > No objection was raised against this statement. Ricky is saying that, because I didn't raise any objection to this statement, I must not have had any technical objections to EHZ. In fact, I had several objections. I posted some of them in the form of a numbered list of technical questions about EHZ. Ricky replied to my questions by saying that I hadn't read Fung's document carefully enough. I posted again saying that I wasn't satisfied with this answer. My objections remain unanswered. I wrote: > > I don't have any misconceptions whatsoever. I now realize that this statement is too strong. What I meant was, I have no misconceptions regarding EHZ and related matters. Ricky writes: > As for Simpson's misconception of the redundancy of "~{" and "~A" in my > proposal, in my June 9 reply, I wrote: > == No, you're wrong. Every time you hit ~{ you switch to non-ASCII mode, > == not GB mode, only when the following character is not ~, then you're in > == GB mode. If your parser switches to GB whenever you see ~{, then it's > == semantically wrong (according to my proposal). I didn't find this explanation very clear or convincing. If we take it literally, it would have to mean that EHZ actually has at least 94 different escape sequences to switch into GB mode, namely ~A plus ~{X where X is any graphical ASCII byte other than ~. But this can't be right, because the X would sometimes also be part of a GB code, hence it could not literally be part of an escape sequence. Maybe the best way to describe this situation is that the semantics of Ricky's concept of escape sequence seem to be different from the normal concept. I'll let Ricky try to untangle this. In the meantime, I stand by my statement that the structure of the escape sequences in EHZ is much more complicated (and perhaps also more subtle and obscure) than in HZ or HZ+. Ricky writes: > On my first post on the ASCII transparency issue, I explicitly stated > that the only drawback for my proposal is two extra bytes per switching > into non-ASCII mode. You may have explicitly stated this, but I explicitly disagreed. The truth is that your proposal has several other drawbacks. > In your reply to my proposal above, you seemed to decide to use > ~0/~1/~2. No, I didn't decide this. It's true that I said at one point, "I am thinking that maybe I will change HZ+S to conform to Ricky's framework. I'm thinking of using ~0, ~1, and ~2 as the escape sequences for Big5." But this statement did not represent a definite decision on my part. Note the word "maybe", and note also that I was considering ~0/~1/~2 only in the context of Ricky's framework. Later, I backed away from my flirtation with Ricky's EHZ framework, primarily because EHZ changed in a way that I didn't like. At the present time, my main objections to EHZ have to do with the complexity of the escape sequence structure, the arbitrariness and complexity of the EHZ-Big5 mapping scheme (influenced by CNS?), and the lack of a simple usage model for Big5 users. Ricky, I'm sorry if you are disappointed or if you were counting on me to endorse EHZ. But after all, I never promised to do so. I still think that EHZ has some technical merit, but I continue to prefer HZ+ for a simple, low-road solution marrying HZ with Big5. > seems to be "lack of clarity." The framework is pretty clear that both > Big5 and CNS are not excluded. How the user uses a particular mapping > is a different issue. I'll leave it to Fung Fung Lee to answer this. Good. I look forward to this explanation from Fung. I wrote: > I think you are giving too much weight to the issue of "maximal ASCII > transparency". It is blinding you to other issues that are much more > important. Ricky replied: > What other much more important issues are you referring to? 1. simplicity. 2. neutrality as between GB and Big5. 3. the need for a clear usage model for Big5 users. 4. ease of implementation. This list is not intended to be exhaustive. -- Steve From Ricky.Yeung@Eng.Sun.COM Tue Jul 12 18:45:16 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA24021; Tue, 12 Jul 94 18:45:16 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16586; Tue, 12 Jul 94 16:42:59 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07559; Tue, 12 Jul 94 16:45:08 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA19837; Tue, 12 Jul 1994 16:00:17 +0800 Date: Tue, 12 Jul 1994 16:00:17 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407122300.AA19837@hk.Eng.Sun.COM> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Tue, 12 Jul 1994 11:48:48 -0400 <199407121548.LAA16728@boole.math.psu.edu> Subject: Getting the facts right (Was Re: reply to Kenichi Handa's points about HZ+) Content-Length: 0 Status: O > From: Stephen G Simpson > Date: Tue, 12 Jul 1994 11:48:48 -0400 > > As an example, consider Big5 users who want to communicate over > channels which are not 8-bit clean. By using HZ+, these users will > need only their normal Big5 software plus very simple Big5<->HZ+ > filters. They will not need multilingual software supporting CNS, GB, > and JIS as would be required by Handa-*, EHZ-*, etc. An additional > advantage for HZ+ users is that they will not experience any > information loss due to CNS translation. If you're using the EHZ framework with Fung Lee's EHZ-Big5 mapping, you don't need "multilingual software supporting CNS, GB, and JIS". Needless to say, there also won't be "information loss due to CNS translation" there. -Ricky From handa@etlken.etl.go.jp Tue Jul 12 20:32:41 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA27522; Tue, 12 Jul 94 20:32:41 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA01260; Wed, 13 Jul 94 10:29:56 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA21991; Wed, 13 Jul 94 10:29:55 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA13693; Wed, 13 Jul 94 10:30:01 JST Date: Wed, 13 Jul 94 10:30:01 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407130130.AA13693@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Tue, 12 Jul 1994 11:48:48 -0400 <199407121548.LAA16728@boole.math.psu.edu> Subject: Re: reply to Kenichi Handa's points about HZ+ Status: O > Kenichi Handa replied: > > My proposals Handa-1 and Handa-2 (previously called as HZ-EA > > and HZ-EA-2) are to be categolized as "CNS translation" > > methods, but they also "guarantees 100 percent round-trip > > accuracy". Stephen G Simpson said: > I don't think so. I'm willing to believe that your translation is > 99.9 percent accurate when restricted to the 13053 common Big5 > characters and the 406 common symbols. And it may also be fairly > accurate for ETen-specific extensions. But your translation cannot be > accurate for vendor-specific extensions other than ETen. For > instance, a lot of people are using KC, and your translation breaks > down for KC-specific extensions. In addition, there is always the > possibility that some people may use translations other than yours, > and this will introduce additional complications and inaccuracies. As for Handa-1, I agree that it may be difficult to prepare and keep updating accurate mappings for all vendors, but Handa-2 doesn't require such mapping. As for a common part of Big5, the mapping is fixed, and how to implement it correctly depends only on the ability of programmer. That's the same as HZ+S, the difference is that Handa-2 requires a little bit more skill. > As an example, consider Big5 users who want to communicate over > channels which are not 8-bit clean. By using HZ+, these users will > need only their normal Big5 software plus very simple Big5<->HZ+ > filters. They will not need multilingual software supporting CNS, GB, > and JIS as would be required by Handa-*, EHZ-*, etc. An additional > advantage for HZ+ users is that they will not experience any > information loss due to CNS translation. It seems that you still misunderstand Handa-* and EHZ-*. They don't require such multilingual software. For Big5 users, Handa-* or EHZ-* encoder/decoder is enough. In addition, Handa-*'s CNS translation doesn't loss information. > Kenichi Handa writes: > > ... from my point of view, Big5 should be > > regarded as not a character set but as an encoding methods > > of (part of) several character sets (including ASCII). Stephen G Simpson said: > I don't think many Big5 users would agree with you. Millions of Big5 > users would almost certainly *not* want to regard Big5 as an encoding > method for CNS+JIS+...+ASCII. Probably most of them have never even > heard of CNS and JIS. Rather, they regard Big5 as an independent, > popular coding standard, one that they use every day and which is well > supported by popular software such as ETen, Chinese Windows, Chinese > Macintosh, etc. For Big5 users, Big5 is just an sole/standard/convenient encoding mechanism of many many characters. I don't clame that they should regard that each character originates to CNS and JIS. Perhaps they don't realize the difference of CHARACTER SET and ENCODING MECHANISM. But, we should realize the difference because we are now discussing ENCODING MECHANISM for some CHARACTER SET. GB, CNS1, CNS2, JIS, ASCII, (and perhaps for you but not for me, BIG5) are CHARACTET SETs. 8bitGB, 8bitCNS, EUS-JIS, *junet* (these are all varients of ISO2022), Shift-JIS, HZ, HZ+S, EHZ, Handa-*, (and not for you, but for me Big5) are all ENCODING MECHANISMs for one or several CHARACTET SETs. > In designing an exchange standard for Chinese on the Internet, I think > we should take the viewpoint of the users into account. If you deny > Big5 its identity, you will almost certainly overlook the needs of > Big5 users. I don't deny Big5s identity. It's an convenient encoding mechanism, and regarding it as so doesn't degrade Big5. --- Ken'ichi HANDA handa@etl.go.jp From simpson@math.psu.edu Wed Jul 13 09:37:03 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA20824; Wed, 13 Jul 94 09:37:03 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id KAA20824; Wed, 13 Jul 1994 10:34:44 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 13 Jul 1994 10:34:42 -0400 Date: Wed, 13 Jul 1994 10:34:42 -0400 Message-Id: <199407131434.KAA18388@boole.math.psu.edu> To: "Ya-Gui Wei" Cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Consolidated Coding Standards, Revision 1 In-Reply-To: <199407130508.BAA18137@leibniz.math.psu.edu> References: <199407130508.BAA18137@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: RO I wrote: > In HZ+, ~> is used > for block 1 and ~< is used for block 2. (My idea is that > stands for > "more" and < stands for "less", suggesting blocks containing the more > and less frequently used characters.) I mention this in case you want > your new proposal to be compatible with HZ+. Ya-Gui replied: > No, actually I am not aware that HZ+ has settled on an > escape sequence. This error on your part is understandable. Ricky Yeung has been telling everybody that the HZ+ escape sequences are constantly changing. In actual fact, they have changed only once. The history is that originally I was using ~1 and ~2 for Big5 blocks 1 and 2. Jianqing Hu and others criticized this choice on the grounds that ~1 and ~2 can occur in C programs, so I changed the escape sequences to ~> and ~<. That change was made several months ago, and HZ+ has been stable ever since. As always, the HZ+ specification document is available for anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/hzp/hzp.doc. Ya-Gui, do you intend to make your new proposal compatible with HZ+? -- Steve From simpson@math.psu.edu Wed Jul 13 10:08:06 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22214; Wed, 13 Jul 94 10:08:06 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA21578; Wed, 13 Jul 1994 11:05:43 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 13 Jul 1994 11:05:41 -0400 Date: Wed, 13 Jul 1994 11:05:41 -0400 Message-Id: <199407131505.LAA18427@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Getting the facts right (Was Re: reply to Kenichi Handa's points about HZ+) In-Reply-To: <199407122346.TAA16711@leibniz.math.psu.edu> References: <199407121548.LAA16728@boole.math.psu.edu> <199407122346.TAA16711@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O I wrote: > As an example, consider Big5 users who want to communicate over > channels which are not 8-bit clean. By using HZ+, these users will > need only their normal Big5 software plus very simple Big5<->HZ+ > filters. They will not need multilingual software supporting CNS, GB, > and JIS as would be required by Handa-*, EHZ-*, etc. An additional > advantage for HZ+ users is that they will not experience any > information loss due to CNS translation. Ricky Yeung replied: > If you're using the EHZ framework with Fung Lee's EHZ-Big5 mapping, you > don't need "multilingual software supporting CNS, GB, and JIS". I disagree. Even if you are only using EHZ-Big5, other people may be using EHZ-CNS-GB-JIS, so you will be stuck (if you want to read the mail and news postings that they generate). > Needless to say, there also won't be "information loss due to CNS > translation" there. Such loss will occur if other EHZ users use Big5->CNS translation. This is one of the many possible EHZ usage models that Fung recommends. -- Steve From simpson@math.psu.edu Wed Jul 13 10:26:59 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA23108; Wed, 13 Jul 94 10:26:59 CDT Received: from leibniz.math.psu.edu by cnd.org (4.1/4.7) id AA19116; Wed, 13 Jul 94 08:25:08 PDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA21704; Wed, 13 Jul 1994 11:23:02 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 13 Jul 1994 11:23:01 -0400 Date: Wed, 13 Jul 1994 11:23:01 -0400 Message-Id: <199407131523.LAA18448@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Handa says that Big5 is not a character set In-Reply-To: <199407130132.VAA17153@leibniz.math.psu.edu> References: <199407121548.LAA16728@boole.math.psu.edu> <199407130132.VAA17153@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O I wrote: > > ... But your translation cannot be > > accurate for vendor-specific extensions other than ETen. For > > instance, a lot of people are using KC, and your translation breaks > > down for KC-specific extensions. In addition, there is always the > > possibility that some people may use translations other than yours, > > and this will introduce additional complications and inaccuracies. Handa replied: > As for Handa-1, I agree that it may be difficult to prepare > and keep updating accurate mappings for all vendors, but > Handa-2 doesn't require such mapping. ... Yes, sorry, I stand corrected. My objection applied only to Handa-1, not to Handa-2. Handa writes: > GB, CNS1, CNS2, JIS, ASCII, (and perhaps for you but not for > me, BIG5) are CHARACTET SETs. 8bitGB, 8bitCNS, EUS-JIS, > *junet* (these are all varients of ISO2022), Shift-JIS, HZ, > HZ+S, EHZ, Handa-*, (and not for you, but for me Big5) are > all ENCODING MECHANISMs for one or several CHARACTET SETs. I find this view of Big5 to be very strange. In my view and I think the view of most people, Big5 is a character set, similar to GB or JIS, with similar functionality. But apparently, for you, Big5 is not a character set. Let's think about the logical consequences of your view. If you deny that Big5 is a character set, then which character set (or sets?) do you think the millions of Big5 users in Taiwan and elsewhere are using every day? Do you think they are using GB, or CNS, or JIS? Or perhaps you think these people are somehow communicating without any character set? -- Steve From CAI%MVF.DecNet@wigate.nic.wisc.edu Wed Jul 13 11:14:16 1994 Return-Path: Received: from vms.macc.wisc.edu by ifcss.org (4.1/IFCSS-Mailer) id AA25212; Wed, 13 Jul 94 11:14:16 CDT Received: from VMSmail by wircs1.DecNet; Wed, 13 Jul 94 11:12 CDT Message-Id: <24071311120158@wircs1.DecNet> Date: Wed, 13 Jul 94 11:12 CDT From: CAI%MVF.DecNet@wigate.nic.wisc.edu Subject: Big-5: official or unofficial ? To: soft-authors@ifcss.org X-Vms-To: WIRCS1::IN%"soft-authors@ifcss.org" Status: O It seems that most people on the net think that Big5 is an unofficial standard "invented" by some big companies. I recently came across a book which described the history of Big5, and it turned out, according to the book, Big5 was officially released standard by some government agencies of ROC between 1981-1986. My impression was that later on III took over the job and released CNS as the current standard. I'll scan the relevent parts and post to this net (in a week? because I am very busy). Until you see the scanned text, I hope you can just hold your breath for a while. cai From simpson@math.psu.edu Wed Jul 13 15:42:08 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA07185; Wed, 13 Jul 94 15:42:08 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id QAA23923; Wed, 13 Jul 1994 16:39:34 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 13 Jul 1994 16:39:32 -0400 Date: Wed, 13 Jul 1994 16:39:32 -0400 Message-Id: <199407132039.QAA18888@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Handa says that Big5 is not a character set In-Reply-To: <199407131943.PAA23605@leibniz.math.psu.edu> References: <199407131943.PAA23605@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O John Delacour writes: > To my mind a "set" in the context of the present discussion is a character > set that can be uniquely identified as a valid component of ISO-2022 -- a > 94*94 set or a 96*96 set or a 128*128 set. All right. So I guess what you and Kenichi Handa are saying here is that Big5 is not a character set, because it is not part of ISO-2022. I don't agree with this view. The ISO-2022 committee does not have a monopoly on the general concept of "character set". The ISO-2022 committee is doing some valuable work, but they are not gods who can dictate how we must structure our communication environment. Whether you and Kenichi and the ISO-2022 committee like it or not, millions of people are using Big5 in their daily work. It is wrong for you to try to ignore the needs of these people. > This is just a confusion of semantics and terminology I don't think so. I think the real issue is the legitimacy of Big5. You and Kenichi are trying to attack Big5 by implying that it is somehow not legitimate or not real. I find this illogical and bizarre. > the problem is certainly that the terms have not been defined. > > For me, in the present context, a "character-set" is the way Ken'ichi > defines it. If the term "character set" has not been defined, then how can you speak of "the way Kenichi defines it"? In actual fact, I don't think he ever did define it, at least not in this forum. He gave some examples, saying that GB and CNS1 and CNS2 and JIS and ASCII are character sets, but that Big5 is not a character set. Obviously this collection of examples falls far short of a general definition, and it's not clear to me what criterion is being used to exclude Big5. I think the common understanding is that a character set is any set of characters or glyphs that are used for communication among some group of people. Examples would be the Roman alphabet, Egyptian hieroglyphics, ASCII, JIS, and Big5. If you and Kenichi have another concept in mind, please tell us. In the absence of a definition, I have no way of knowing for sure what Kenichi is talking about when he says that Big5 is not a character set (though I can make some pretty good guesses). Hu Bo has stated an opinion that governments should have the authoritative role, i.e. that only government-endorsed character sets should be considered legitimate and worthy of attention. In my opinion, this view is appropriate to Big Brother in the novel "1984", but it is not appropriate for residents of free or semi-free countries. Communication is not a government monopoly! -- Steve From simpson@math.psu.edu Wed Jul 13 17:07:28 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA11126; Wed, 13 Jul 94 17:07:28 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id SAA24583; Wed, 13 Jul 1994 18:04:55 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Wed, 13 Jul 1994 18:04:51 -0400 Date: Wed, 13 Jul 1994 18:04:51 -0400 Message-Id: <199407132204.SAA18993@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: what's wrong with CNS In-Reply-To: <199407122122.RAA14269@leibniz.math.psu.edu> References: <199407122122.RAA14269@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O I wrote: > > HZ+ focuses on 7-bit Chinese by supporting the two > >most popular Chinese character coding schemes, GB and Big5. Other > >proposals are focused on other goals: multilingual extensibility, > >"maximal ASCII transparency", efficiency of mapping schemes, CNS > >support (odd, because there don't seem to be any CNS users), etc. etc. John Delacour replied: > I don't follow your reasoning, Steve. ALL the proposals are "focused" on > GB and Big5 and any of them will perform the task required of them, though > there has been no proper presentation of the Unicode alternative so far. I agree that all of the proposals support GB and Big5 in some fashion. (A partial exception to this is the Handa-* proposals, which lack any kind of direct Big5 support. Handa tried to remedy this defect by defining an extremely complicated mapping of Big5 into the union of CNS, GB, and JIS. This mapping is not part of the Handa-* proposals, but Handa points out that it can be used in conjunction with them. I view this as a very poor way of supporting Big5, but it is certainly better than no Big5 support at all.) However, although all of the proposals support GB and Big5 to some extent, I don't think it's correct to say that they all *focus* on GB and Big5 support. Many of them have additional goals, such as multilingual extensibility, "maximal ASCII transparency", CNS support, CNS compatibility, conservation of CPU cycles, etc. In my opinion, these subsidiary goals have caused many of the proposals to lose sight of what I regard as the primary goal, namely the development of a low-road Chinese standard for use on the Internet. Aspects of the primary goal are sacrificed to what I regard as secondary goals. GB/Big5 neutrality is sacrificed to "maximal ASCII transparency". Vendor-specific Big5 is sacrificed to CNS. Simplicity is sacrificed to a desire for some unspecified kind of CNS compatibility. Etc. > I don't understand your strong antipathy towards CNS. I'm antipathetic to CNS for one reason, namely because CNS is detracting from what I think should be one of our main goals, namely excellent Big5 support. > CNS is the CHILD of Big5 and fully compatible with Big5 so far as > planes 1 & 2 are concerned. I don't know what you mean by "child". As for compatibility, CNS is by its very nature incompatible with Big5. They don't agree on even one code point, and there is no accurate way to translate Big5 into CNS. They are different coding systems, that's all. > You might argue that your code will operate faster on Big5<->7-bit > conversion than code that relies on CNS, but I doubt if the difference > would be be worth bothering about You're right in saying that my code is much faster than CNS conversion. But yes, I don't regard this speed issue as terribly important. To my mind, the really important issue is 100 percent Big5 compatibility, which CNS conversion can never provide. > and the advantage of an interchange code > based on CNS is that those 1.25 people in the world (according to you) who > DO use CNS would be able to read the stuff. I don't regard this as much of an advantage. I don't know of one single CNS user, anywhere in the world. Furthermore, I have good reason to believe that, if indeed there are some CNS users lurking somewhere (perhaps in III or some other obscure ROC government agency), then these mysterious CNS users are also Big5 users and have ready access to Big5 software. So these mythical CNS users do not give us any reason to use CNS. Where did you get your figure of 1.25 CNS users world wide? > You have twice now said that Handa considers Big5 as a method for > partially encoding other coding systems (some popular, some not) > such as CNS, JIS, GB, and ASCII. But I'm right about this. It may seem hard to believe, but it's true, he actually did say that, several times. > -- I can't see how ANYONE could infer such nonsense I can't either, but there it is, he inferred it and he said it for all to read. Why not ask him what he is talking about? It is indeed a bizarre way of looking at Big5. > The question of "vendor codes" has also been red herring from the very > beginning. There are for more important things to consider than the whims > of a few vendors. I don't view vendor-specific codes as a red herring. They are not as important as some other aspects of Big5, but they are in fact fairly important. Surely even the most determined enemy of Big5 has to admit that the vendor-specific codes provide some alphabets and graphical symbols and Chinese characters that at least some Big5 users and vendors regard as important and/or useful. -- Steve From Ricky.Yeung@Eng.Sun.COM Wed Jul 13 19:02:10 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA14823; Wed, 13 Jul 94 19:02:10 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28596; Wed, 13 Jul 94 16:59:52 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08955; Wed, 13 Jul 94 16:59:52 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA21324; Wed, 13 Jul 1994 17:00:33 +0800 Date: Wed, 13 Jul 1994 17:00:33 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407140000.AA21324@hk.Eng.Sun.COM> To: yawei@cs.indiana.edu, ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Wed, 13 Jul 1994 10:34:42 -0400 <199407131434.KAA18388@boole.math.psu.edu> Subject: Some facts (Was Re: Consolidated Coding Standards, Revision 1) Content-Length: 1739 Status: O > From: Stephen G Simpson > Date: Wed, 13 Jul 1994 10:34:42 -0400 > > Ya-Gui replied: > > No, actually I am not aware that HZ+ has settled on an > > escape sequence. > > This error on your part is understandable. Ricky Yeung has been > telling everybody that the HZ+ escape sequences are constantly > changing. In actual fact, they have changed only once. The history > is that originally I was using ~1 and ~2 for Big5 blocks 1 and 2. > Jianqing Hu and others criticized this choice on the grounds that ~1 > and ~2 can occur in C programs, so I changed the escape sequences to > ~> and ~<. That change was made several months ago, and HZ+ has been > stable ever since. On June 2 1994, Simpson wrote: ++ This is something like the reasoning behind my original HZ++ proposal a ++ long time ago, which used ~1{ and ~2{. At that time, a lot of people ++ expressed the opinion that all the escape sequences should be only two ++ bytes in length, so I changed them to ~1 and ~2 and that is what they ++ have been until now. Today is July 13 1994, can't imagine how June 2 1994 could be considered "several months ago". :-) On June 13 1994, Simpson wrote: ++ This framework looks good. I am thinking that maybe I will change ++ HZ+S to conform to Ricky's framework. I'm thinking of using ~0, ~1, ++ and ~2 as the escape sequences for Big5. (~1 and ~2 for ETen Big5 ++ blocks 1 and 2, ~0 for the ETen user-defined area as pointed out by ++ Sandstrom. Note that this choice of escapes is in a sense ISO 2022 ++ compliant, since 0, 1, 2, ... are reserved as ISO 2022 final ++ characters for application-specific character sets.) -Ricky From Ricky.Yeung@Eng.Sun.COM Wed Jul 13 20:10:47 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA16480; Wed, 13 Jul 94 20:10:47 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10438; Wed, 13 Jul 94 18:08:25 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19055; Wed, 13 Jul 94 18:08:27 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA21413; Wed, 13 Jul 1994 18:09:28 +0800 Date: Wed, 13 Jul 1994 18:09:28 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407140109.AA21413@hk.Eng.Sun.COM> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Wed, 13 Jul 1994 11:05:41 -0400 <199407131505.LAA18427@boole.math.psu.edu> Subject: Re: Getting the facts right (Was Re: reply to Kenichi Handa's points about HZ+) Content-Length: 2045 Status: O What I want to point out is that the "advantages" that Simpson is trying to single out for HZ+S apply well to others such as HZ-2, and the EHZ framework with Fung Lee's EHZ-Big5 mapping. > From: Stephen G Simpson > Date: Wed, 13 Jul 1994 11:05:41 -0400 > > I wrote: > > As an example, consider Big5 users who want to communicate over > > channels which are not 8-bit clean. By using HZ+, these users will > > need only their normal Big5 software plus very simple Big5<->HZ+ > > filters. They will not need multilingual software supporting CNS, GB, > > and JIS as would be required by Handa-*, EHZ-*, etc. An additional > > advantage for HZ+ users is that they will not experience any > > information loss due to CNS translation. > > Ricky Yeung replied: > > If you're using the EHZ framework with Fung Lee's EHZ-Big5 mapping, you > > don't need "multilingual software supporting CNS, GB, and JIS". > > I disagree. Even if you are only using EHZ-Big5, other people may be > using EHZ-CNS-GB-JIS, so you will be stuck (if you want to read the > mail and news postings that they generate). Let me put it this way: If a Big5 user converts Big5 to JIS, and if your EHZ filter doesn't decode JIS, you will be stuck. Similarily, HZ+S users will be stuck because it (not just the implementation, but the spec as well) doesn't support JIS. For these Big5 users, they "need multilingual software supporting JIS" and/or spec-level support as would be "required by HZ+S." > > Needless to say, there also won't be "information loss due to CNS > > translation" there. > > Such loss will occur if other EHZ users use Big5->CNS translation. > This is one of the many possible EHZ usage models that Fung > recommends. Let me put it this way: Such loss will also occur if HZ+S users use Big5->GB translation. A "disadvantage" for HZ+S users is that they will experience information loss due to GB translation. -Ricky From handa@etlken.etl.go.jp Wed Jul 13 21:28:28 1994 Received: from etlpost ([192.31.197.33]) by ifcss.org (4.1/IFCSS-Mailer) id AA19024; Wed, 13 Jul 94 21:28:28 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA13618; Thu, 14 Jul 94 11:25:27 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA07882; Thu, 14 Jul 94 11:25:26 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA14495; Thu, 14 Jul 94 11:25:32 JST Date: Thu, 14 Jul 94 11:25:32 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407140225.AA14495@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Wed, 13 Jul 1994 11:23:01 -0400 <9407131546.AA10585@sutgate.bitnetjp.ad.jp> Subject: Re: Handa says that Big5 is not a character set Status: O > Handa writes: > > GB, CNS1, CNS2, JIS, ASCII, (and perhaps for you but not for > > me, BIG5) are CHARACTET SETs. 8bitGB, 8bitCNS, EUS-JIS, > > *junet* (these are all varients of ISO2022), Shift-JIS, HZ, > > HZ+S, EHZ, Handa-*, (and not for you, but for me Big5) are > > all ENCODING MECHANISMs for one or several CHARACTET SETs. Stephen G Simpson said: > I find this view of Big5 to be very strange. In my view and I think > the view of most people, Big5 is a character set, similar to GB or > JIS, with similar functionality. But apparently, for you, Big5 is not > a character set. CHARACTER SET is not sipmly a set of characters. CHARACTER SET should, at least for me, contain fixed number of characters (without duplication) in a fixed order. All who are using a character of particular code point in particular CHARACTER SET should be assured that they are using the same character. Apparently, Big5 including vendor part doesn't satify it. While considering only non-private part of one of any variants of Big5 (e.g. Big5-ETen), it may be able to regard it as a CHARACTER SET but quite badly designed one. But, this results in that we have many CHARACTER SETs resembling each other very closely. This is just a way of how to see the world. I prefer seeing the world more simply by regarding Big5 as an ENCODING MECHANISM. Stephen G Simpson said: > Let's think about the logical consequences of your view. If you deny > that Big5 is a character set, then which character set (or sets?) do > you think the millions of Big5 users in Taiwan and elsewhere are using > every day? Do you think they are using GB, or CNS, or JIS? Or Perhaps so. What's wrong? Big5 users are already in a rich multilingual environment (although restricted). :-) Anyway, I think most end-users just know that they are using each character, without considering where it originates from. ASCII, GB, CNS, or JIS are all just characters for them. Stephen G Simpson said: > You're right in saying that my code is much faster than CNS > conversion. But yes, I don't regard this speed issue as terribly > important. To my mind, the really important issue is 100 percent Big5 > compatibility, which CNS conversion can never provide. Why do you keep saying that after you agreed as below: ------------------------------------------------------------ Stephen G Simpson said: > > > ... But your translation cannot be > > > accurate for vendor-specific extensions other than ETen. For > > > instance, a lot of people are using KC, and your translation breaks > > > down for KC-specific extensions. In addition, there is always the > > > possibility that some people may use translations other than yours, > > > and this will introduce additional complications and inaccuracies. > Handa replied: > > As for Handa-1, I agree that it may be difficult to prepare > > and keep updating accurate mappings for all vendors, but > > Handa-2 doesn't require such mapping. ... Stephen G Simpson said: > Yes, sorry, I stand corrected. My objection applied only to Handa-1, > not to Handa-2. --- Ken'ichi HANDA handa@etl.go.jp From Ricky.Yeung@Eng.Sun.COM Thu Jul 14 02:49:08 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA28273; Thu, 14 Jul 94 02:49:08 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22892; Thu, 14 Jul 94 00:46:48 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04452; Thu, 14 Jul 94 00:46:57 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA21661; Thu, 14 Jul 1994 00:47:56 +0800 Date: Thu, 14 Jul 1994 00:47:56 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407140747.AA21661@hk.Eng.Sun.COM> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Cc: handa@etlken.etl.go.jp (Kenichi Handa) In-Reply-To: Stephen G Simpson's message of Tue, 12 Jul 1994 16:19:22 -0400 <199407122019.QAA17061@boole.math.psu.edu> Subject: Re: Getting the record straight (Was Re: reply to Ricky's criticisms) Content-Length: 5832 Status: O > From: Stephen G Simpson > Date: Tue, 12 Jul 1994 16:19:22 -0400 > > Ricky Yeung writes: > > == Ok, now we're settled on the technical front. Let's talk about > > == politics. > > > > No objection was raised against this statement. > > Ricky is saying that, because I didn't raise any objection to this > statement, I must not have had any technical objections to EHZ. In I'm just merely pointed out the fact that about a month ago, AFTER a couple-week-long debate, Simpson said in public that "My view is that your suggestions make a lot of technical sense" and "I am thinking that maybe I will change HZ+S to conform to Ricky's framework." And Simpson raised no objection to my above statement. Again, I'll let the readers be the judge on Simpson's statement "You did not settle anything". > fact, I had several objections. I posted some of them in the form of > a numbered list of technical questions about EHZ. Ricky replied to my > questions by saying that I hadn't read Fung's document carefully > enough. I posted again saying that I wasn't satisfied with this > answer. My objections remain unanswered. His "objections" (actually questions) refer particularly to Fung Lee's EHZ-Big5 mapping, not the EHZ framework. > I wrote: > > > I don't have any misconceptions whatsoever. > > I now realize that this statement is too strong. What I meant was, > I have no misconceptions regarding EHZ and related matters. [...deleted...] > I didn't find this explanation very clear or convincing. If we take > it literally, it would have to mean that EHZ actually has at least 94 > different escape sequences to switch into GB mode, namely ~A plus ~{X > where X is any graphical ASCII byte other than ~. But this can't be > right, because the X would sometimes also be part of a GB code, hence > it could not literally be part of an escape sequence. Maybe the best > way to describe this situation is that the semantics of Ricky's > concept of escape sequence seem to be different from the normal > concept. I'll let Ricky try to untangle this. In the meantime, I > stand by my statement that the structure of the escape sequences in > EHZ is much more complicated (and perhaps also more subtle and > obscure) than in HZ or HZ+. This is an obvious misconception. Just for fun, I'll give the following analogy. Let's consider the token ">" in C. To recognize that token, you need to look ahead. Whatever follows helps the recognition but it's not part of the ">" token. For instance, in the expression "a>b", you won't say "b" is part of the ">" token. Got it? :-) I remember someone (Handa?) once said that EHZ is "common sense", looks like one needs some knowledge on elementary parsing first. :-) > > In your reply to my proposal above, you seemed to decide to use > > ~0/~1/~2. > > No, I didn't decide this. It's true that I said at one point, "I am > thinking that maybe I will change HZ+S to conform to Ricky's > framework. I'm thinking of using ~0, ~1, and ~2 as the escape > sequences for Big5." But this statement did not represent a definite > decision on my part. Note the word "maybe", and note also that I was > considering ~0/~1/~2 only in the context of Ricky's framework. Later, > I backed away from my flirtation with Ricky's EHZ framework, primarily > because EHZ changed in a way that I didn't like. At the present time, > my main objections to EHZ have to do with the complexity of the escape > sequence structure, the arbitrariness and complexity of the EHZ-Big5 > mapping scheme (influenced by CNS?), and the lack of a simple usage > model for Big5 users. My framework DIDN'T change. Some may want to play around with words, I just want to get the facts straight. > Ricky, I'm sorry if you are disappointed or if you were counting on me > to endorse EHZ. But after all, I never promised to do so. I still Sorry, I never think that I need your endorsement. [BTW, I think that kind of statements are really "silly and pointless" (in Simpson's own terms :-). ] [...deleted...] > Ricky replied: > > What other much more important issues are you referring to? > > 1. simplicity. 2. neutrality as between GB and Big5. 3. the need > for a clear usage model for Big5 users. 4. ease of implementation. > This list is not intended to be exhaustive. I dont't think they are much more important than the ASCII transparency issue. Let's look at them one at a time (again) anyway (and even though your terms are very vague). 1. Simplicity. If you're referring to the escape sequence, EHZ takes two extra bytes per switching into non-ASCII mode. I think they're worth every bit. The history of zW and HZ is a good lesson on that byte-count issue. If you're referring to the mappings, I think HZ-2 has a simpler mapping than HZ+S. I prefer Fung Lee's EHZ-Big5 mapping. 2. Neutrality between GB and Big5. I've been saying that EHZ is more neutral than HZ+S because it gives equal ASCII transparency to ALL code schemes. I refer the readers to the soft-author mail archive (ifcss.org:/software/soft-author-discussion/9406.log) on this much debated "political issues" and "fairness" between Simpson and me. 3. "The need for a clear usage model for Big5 users". It's a pretty vague statement. Can you clearly define your term "usage model"? What's the "clear usage model for Big5 users" for HZ+S? What's so unclear about EHZ? 4. Ease of implementation. If you're referring to the mapping implementation, I think HZ-2 is much simpler than HZ+S. Why is that more important than ASCII transparency? -Ricky From simpson@math.psu.edu Thu Jul 14 14:20:31 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA21318; Thu, 14 Jul 94 14:20:31 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA05654; Thu, 14 Jul 1994 15:17:54 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Thu, 14 Jul 1994 15:17:52 -0400 Date: Thu, 14 Jul 1994 15:17:52 -0400 Message-Id: <199407141917.PAA24210@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: changes in HZ+ In-Reply-To: <199407140000.UAA26661@leibniz.math.psu.edu> References: <199407131434.KAA18388@boole.math.psu.edu> <199407140000.UAA26661@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Ricky Yeung writes: > Today is July 13 1994, can't imagine how June 2 1994 could be considered > "several months ago". :-) OK, yes, I stand corrected. Ricky is reminding me of something that I had forgotten. Namely, when I first proposed a scheme similar to HZ+ back in April 1994, the original escape sequences for Big5 blocks 1 and 2 were ~1{ and ~2{. I don't have complete records, but it seems to me that that choice was in effect for only a matter of a few days, not more than a week. Some people in soft-authors expressed a preference for 2-byte escape sequences, so I changed the them to ~1 and ~2, and that's what I used in my first implementation. Later, some other people complained that ~1 and ~2 could occur in C programs, so I changed the escapes to ~> and ~<. Again, I don't have a record of exactly when that happened, but surely it was at least a month ago. (I guess it just seemed like several months!) Apart from these minor changes to the escape sequences, HZ+ has been stable from the beginning. In particular, the 7-bit representation of Big5 has never changed at all. Furthermore, the HZ+ specification and sample implementations have been continuously available for anonymous FTP for several months (at ftp.math.psu.edu, /pub/simpson/chinese/hzp), so it was always possible for everyone to inspect this material. I think my willingness to accept constructive criticism and modify HZ+ as needed has been a point in favor of HZ+. I don't think Ricky is justified in raking me over the coals for this. After all, HZ+ was still in the experimental stage. I feel that this experimental period will come to an end rather soon, and at the present time I don't see any need for further changes in HZ+. -- Steve From simpson@math.psu.edu Thu Jul 14 14:35:09 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22108; Thu, 14 Jul 94 14:35:09 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA05834; Thu, 14 Jul 1994 15:32:27 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Thu, 14 Jul 1994 15:32:25 -0400 Date: Thu, 14 Jul 1994 15:32:25 -0400 Message-Id: <199407141932.PAA24227@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Getting the facts right (Was Re: reply to Kenichi Handa's points about HZ+) In-Reply-To: <199407140108.VAA26900@leibniz.math.psu.edu> References: <199407131505.LAA18427@boole.math.psu.edu> <199407140108.VAA26900@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Ricky Yeung writes: > If a Big5 user converts Big5 to JIS, and if your EHZ filter doesn't decode > JIS, you will be stuck. Similarily, HZ+S users will be stuck because it > (not just the implementation, but the spec as well) doesn't support JIS. > For these Big5 users, they "need multilingual software supporting JIS" > and/or spec-level support as would be "required by HZ+S." Yes, you could say it this way if you insist. But there is still a big difference between EHZ and HZ+ in this respect. The difference is that EHZ encourages Big5 users to convert Big5 to an unholy mixture of GB, CNS and JIS (something like Handa-*, but worse). By "encourages", I mean that such conversion is one of the many alternative Big5 usage models that the author of EHZ has recommended (with a straight face). By contrast, HZ+ in no way encourages this kind of perversity. Under HZ+, the only Big5 usage model is Big5 -> HZ+ -> Big5 conversion, which is always 100 percent accurate (see also my sample implementation, available for anonymous FTP). Ricky writes: > Such loss will also occur if HZ+S users use Big5->GB translation. A > "disadvantage" for HZ+S users is that they will experience information > loss due to GB translation. This is nonsense. It is so mixed up that I don't have time to refute it in detail. Let me say only that HZ+ in no way requires or encourages Big5->GB translation. Ricky is trying to slander HZ+ for no reason. -- Steve From simpson@math.psu.edu Thu Jul 14 15:00:16 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA23305; Thu, 14 Jul 94 15:00:16 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA05973; Thu, 14 Jul 1994 15:57:05 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Thu, 14 Jul 1994 15:57:04 -0400 Date: Thu, 14 Jul 1994 15:57:04 -0400 Message-Id: <199407141957.PAA24253@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Handa says that Big5 is not a character set In-Reply-To: <199407140227.WAA27155@leibniz.math.psu.edu> References: <9407131546.AA10585@sutgate.bitnetjp.ad.jp> <199407140227.WAA27155@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O I wrote: > > Let's think about the logical consequences of your view. If you deny > > that Big5 is a character set, then which character set (or sets?) do > > you think the millions of Big5 users in Taiwan and elsewhere are using > > every day? Do you think they are using GB, or CNS, or JIS? Or ... Handa replied: > Perhaps so. What's wrong? Big5 users are already in a rich > multilingual environment (although restricted). :-) Perhaps so? You mean Big5 users are (perhaps) using a multilingual GB, CNS, and JIS environment, without even knowing it? Although you wrote a smiley , I think you really do believe this. Incredible! Once again, I think you are trying to deny Big5 its identity. You are seeing everything from the viewpoint of ISO-2022 only. Since ISO-2022 doesn't include Big5, you cannot admit that Big5 is real. I wrote (to John): > > You're right in saying that my code is much faster than CNS > > conversion. But yes, I don't regard this speed issue as terribly > > important. To my mind, the really important issue is 100 percent Big5 > > compatibility, which CNS conversion can never provide. Handa replied: > Why do you keep saying that after you agreed as below: > ... > Stephen G Simpson said: > > Yes, sorry, I stand corrected. My objection applied only to Handa-1, > > not to Handa-2. The reason I keep saying it is because it's true. Just to avoid misunderstanding, let me say it yet again. CNS conversion can never represent Big5 accurately. The Handa-* proposals are not based on CNS conversion alone. Rather, they are based on conversion of Big5 into an unholy mixture of CNS, GB, JIS, ASCII, and some private codes. Furthermore, as I recall, these conversions are not actually part of the Handa-* specifications. They were only suggested for use with HZ-EA. And even with all this, I still don't think HZ-EA or Handa-* can provide complete accuracy in transmitting Big5. (Not surprising, given your unusual view of Big5.) Are the latest HZ-EA or Handa-* specifications available for anonymous FTP somewhere? -- Steve From simpson@math.psu.edu Thu Jul 14 15:23:45 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA24360; Thu, 14 Jul 94 15:23:45 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id QAA06103; Thu, 14 Jul 1994 16:21:11 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Thu, 14 Jul 1994 16:21:09 -0400 Date: Thu, 14 Jul 1994 16:21:09 -0400 Message-Id: <199407142021.QAA24282@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Handa says that Big5 is not a character set In-Reply-To: <199407140227.WAA27155@leibniz.math.psu.edu> References: <9407131546.AA10585@sutgate.bitnetjp.ad.jp> <199407140227.WAA27155@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Kenichi Handa writes: > > > GB, CNS1, CNS2, JIS, ASCII, (and perhaps for you but not for > > > me, BIG5) are CHARACTET SETs. 8bitGB, 8bitCNS, EUS-JIS, > > > *junet* (these are all varients of ISO2022), Shift-JIS, HZ, > > > HZ+S, EHZ, Handa-*, (and not for you, but for me Big5) are > > > all ENCODING MECHANISMs for one or several CHARACTET SETs. Please note that Handa is saying explicitly that Big5 is not a character set. Rather, according to Handa, Big5 is an encoding mechanism for one or several character sets. In the above, Handa does not specify which character sets are encoded by Big5, but from other postings I think he has in mind parts of GB, CNS, JIS, and ASCII, maybe ISO-8859-* too. I have already pointed out one bizarre consequence of Handa's view, namely that Big5 users in Taiwan and elsewhere are somehow communicating without any character set, or at least they don't know what character set they are communicating with. Now I'd like to point out another strange consequence. Namely, I'd like Handa to answer the following: In Handa's view of the world, which character sets are encoded by the HZ+S encoding mechanism? As the inventor of HZ+S (now also known as HZ+), I intended it to be an encoding mechanism for the ASCII, Big5, and GB character sets. But apparently, according to Handa, I was confused. :-) Obviously HZ+S can't be an encoding mechanism for the Big5 character set, because Big5 isn't after all a character set! :-) Silly me! I'd like to thank Handa and Yeung for pointing out that I'm completely confused not only about Handa-* and EHZ-*, but even my own proposal, HZ+ !!! :-) Could somebody please rescue me from my delusions? :-) -- Steve From Ricky.Yeung@Eng.Sun.COM Thu Jul 14 16:21:17 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA27314; Thu, 14 Jul 94 16:21:17 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12570; Thu, 14 Jul 94 14:18:46 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA11392; Thu, 14 Jul 94 14:18:58 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA23938; Thu, 14 Jul 1994 14:19:51 +0800 Date: Thu, 14 Jul 1994 14:19:51 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407142119.AA23938@hk.Eng.Sun.COM> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Thu, 14 Jul 1994 16:21:09 -0400 <199407142021.QAA24282@boole.math.psu.edu> Subject: Re: Handa says that Big5 is not a character set Content-Length: 453 Status: O > From: Stephen G Simpson > Date: Thu, 14 Jul 1994 16:21:09 -0400 > > I'd like to thank Handa and Yeung for pointing out that I'm completely > confused not only about Handa-* and EHZ-*, but even my own proposal, > HZ+ !!! :-) Could somebody please rescue me from my delusions? :-) Excuse me. When did I mention anything about your confusion on Handa-* and your own HZ+S? It's a poor cheap shot. -Ricky From cyl Thu Jul 14 19:58:39 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA04716; Thu, 14 Jul 94 19:58:39 CDT Date: Thu, 14 Jul 1994 19:58:38 -0500 (CDT) From: Nelson CHIN Subject: new list maintainer To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Xiaofei may not have Internet connection in the upcoming year, and thus has handed over the maintainance of soft-authors over to me. For starters, SUBSCRIPTION: to subscribe/unsubscribe to soft-authors, just drop me an email at cyl@ifcss.org For vocalists, FLAME-WARS: no more flame-wars allowed on this list. If you feel your toes has been stepped on, bring it to personal email, and settle it once and for all. If you really want settle in public, bring to ccnet-l or acc, not here. Thanks for you cooperation. Nelson From nsysu11@cc.nsysu.edu.tw Thu Jul 14 20:47:08 1994 Return-Path: Received: from cc.nsysu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA06595; Thu, 14 Jul 94 20:47:08 CDT Received: (from nsysu11@localhost) by cc.nsysu.edu.tw (8.6.9/8.6.9) id JAA01546; Fri, 15 Jul 1994 09:39:56 +0800 Date: Fri, 15 Jul 1994 09:38:08 +0800 (CST) From: Werner Lemberg Subject: Subscription To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O I don't know if my last try to subscribe a few days ago came up to this list - I got no reply. Thus once again: please subscribe me to this list. Werner From handa@etlken.etl.go.jp Thu Jul 14 21:42:08 1994 Received: from etlpost (etlpost.etl.go.jp) by ifcss.org (4.1/IFCSS-Mailer) id AA08547; Thu, 14 Jul 94 21:42:08 CDT Received: from etlpom.etl.go.jp by etlpost (5.67+1.6W/2.7W) id AA24911; Fri, 15 Jul 94 11:36:16 JST Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER) id AA21765; Fri, 15 Jul 94 11:36:15 JST Received: by etlken.etl.go.jp (4.1/6.4J.6-ETL.SLAVE) id AA00446; Fri, 15 Jul 94 11:17:02 JST Date: Fri, 15 Jul 94 11:17:02 JST From: handa@etlken.etl.go.jp (Kenichi Handa) Return-Path: Message-Id: <9407150217.AA00446@etlken.etl.go.jp> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Thu, 14 Jul 1994 15:57:04 -0400 <199407141957.PAA24253@boole.math.psu.edu> Subject: Re: Handa says that Big5 is not a character set Status: O First of all, I'm not claiming that eveyone should have the same view as mine as for this CHARACTER SET topic. I just wanted to suggest a different view of Big5 to have the rationale behind Handa-* understood. Stephen G Simpson said: > Perhaps so? You mean Big5 users are (perhaps) using a multilingual > GB, CNS, and JIS environment, without even knowing it? Although you > wrote a smiley , I think you really do believe this. Incredible! You wrote some Big5 users were reading fj.* news groupd with Big5. Doesn't it mean they have a kind of multilingual environment? > Once again, I think you are trying to deny Big5 its identity. You are > seeing everything from the viewpoint of ISO-2022 only. Since ISO-2022 > doesn't include Big5, you cannot admit that Big5 is real. Definitely NO. I wrote my view about the requirement for CHARACTER SET and the reason why Big5 doesn't satisfy it. It doesn't include any reference to ISO-2022. Stephen G Simpson said: > I think the common understanding is that a character set is any set of > characters or glyphs that are used for communication among some group > of people. With this understanding, we can even conclude that there exist a big character set (ASCII-BIG5) which contains all characters in ASCII and BIG5. How do you think? It's difficult to define clearly what CHARACTER SET is, but it should, at least, have some policy (language, culture, environment, ...) in the collection of characters. In addition, if we admit the existance of multiple CHARACTER SETs, it is desirable that each CHARACTER SET is exclusive. > but it is not appropriate for residents of free or semi-free > countries. Communication is not a government monopoly! I too agree this. All my note about Big5 is purely from technical point. > The Handa-* proposals are not based on CNS conversion alone. Rather, Ok, I understand about this. So, I don't have to apply your statement "CNS translation cannot achieve anything like this kind of accuracy." to Handa-*. > Furthermore, as I recall, > these conversions are not actually part of the Handa-* specifications. > They were only suggested for use with HZ-EA. > ... > Are the latest HZ-EA or Handa-* specifications available for anonymous > FTP somewhere? Hmmm, your pointing is reasonable. I should have put complete document somewhere. I'll prepare it as soon as possible. > And even with all this, I still don't think HZ-EA or Handa-* can > provide complete accuracy in transmitting Big5. Have you tried my program I posted a few weeks ago? --- Ken'ichi HANDA handa@etl.go.jp From Ricky.Yeung@Eng.Sun.COM Fri Jul 15 03:58:51 1994 Return-Path: Received: from Sun.COM by ifcss.org (4.1/IFCSS-Mailer) id AA19790; Fri, 15 Jul 94 03:58:51 CDT Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03435; Fri, 15 Jul 94 01:56:04 PDT Received: from hk.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA15612; Fri, 15 Jul 94 01:56:23 PDT Received: by hk.Eng.Sun.COM (5.0/SMI-SVR4) id AA01131; Fri, 15 Jul 1994 01:57:10 +0800 Date: Fri, 15 Jul 1994 01:57:10 +0800 From: Ricky.Yeung@Eng.Sun.COM (Ricky Yeung) Message-Id: <9407150857.AA01131@hk.Eng.Sun.COM> To: simpson@math.psu.edu Cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org In-Reply-To: Stephen G Simpson's message of Thu, 14 Jul 1994 15:32:25 -0400 <199407141932.PAA24227@boole.math.psu.edu> Subject: Re: Getting the facts right (Was Re: reply to Kenichi Handa's points about HZ+) Content-Length: 1565 Status: O > From: Stephen G Simpson > Date: Thu, 14 Jul 1994 15:32:25 -0400 > > Yes, you could say it this way if you insist. But there is still a > big difference between EHZ and HZ+ in this respect. The difference is > that EHZ encourages Big5 users to convert Big5 to an unholy mixture of > GB, CNS and JIS (something like Handa-*, but worse). By "encourages", You're wrong. EHZ doesn't "encourage" or "recommend" the conversion of Big5 to GB/CNS/JIS. It's only Handa's proposal that puts a restriction on EHZ to not to have EHZ-Big5 mapping and requires that kind of conversion instead. > I mean that such conversion is one of the many alternative Big5 usage > models that the author of EHZ has recommended (with a straight face). Which author? I didn't say so. If you're talking about Fung Fung Lee, I don't recall him saying that either. The fact that he proposed EHZ-Big5 is a clear indication that he didn't recommend such conversion. > Ricky writes: > > Such loss will also occur if HZ+S users use Big5->GB translation. A > > "disadvantage" for HZ+S users is that they will experience information > > loss due to GB translation. > > This is nonsense. It is so mixed up that I don't have time to refute > it in detail. Let me say only that HZ+ in no way requires or > encourages Big5->GB translation. Ricky is trying to slander HZ+ for > no reason. If you replace the terms GB by CNS, HZ+S by EHZ, and Ricky by Simpson, you may see the light. -Ricky From simpson@math.psu.edu Fri Jul 15 10:48:45 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA02486; Fri, 15 Jul 94 10:48:45 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id LAA13101; Fri, 15 Jul 1994 11:45:55 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 15 Jul 1994 11:45:53 -0400 Date: Fri, 15 Jul 1994 11:45:53 -0400 Message-Id: <199407151545.LAA25602@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: Handa says that Big5 is not a character set In-Reply-To: <9407150217.AA00446@etlken.etl.go.jp> References: <199407141957.PAA24253@boole.math.psu.edu> <9407150217.AA00446@etlken.etl.go.jp> Reply-To: simpson@math.psu.edu Status: O Kenichi Handa writes: > First of all, I'm not claiming that eveyone should have the > same view as mine as for this CHARACTER SET topic. I just > wanted to suggest a different view of Big5 to have the > rationale behind Handa-* understood. Yes. Handa-* does not support Big5, because according to you, Big5 is not a character set and therefore cannot be coded by any coding system. Although I don't agree with your viewpoint, I can follow some of the steps in your reasoning, in an abstract sense. I'd like to point out yet another strange consequence of your viewpoint. You say that Big5 is not a character set but rather an encoding system for one or several character sets. What character sets do you have in mind? I guess you have in mind a mixture of parts of GB, CNS, JIS, ASCII, ISO-8859-*, and some private characters. From this point of view, your mapping of Big5 into such a mixture is actually a *decoding*. However, in the nature of things, decoding always follows encoding, right? In other words, nothing can be decoded until after it has been previously encoded, right? My question is, if conversion of Big5 into GB+CNS+JIS+... is a decoding process, then when did the original encoding process take place? Did it take place in the brains of the Big5 users? This strikes me as yet another point where your viewpoint is not in agreement with the facts. I'm only trying to understand your viewpoint, which strikes me as very unusual and strange. My own viewpoint is, of course, quite different. My view (and I think the view of most people) is that Big5 is indeed a character set. In fact, it is an important character set which is used by millions of people every day. For this reason, my HZ+ proposal supports the Big5 character set by means of a simple encoding into the graphical ASCII range. This strikes me as a very sensible thing to do. Does anyone else agree with me on this? Could somebody please tell me that I'm not crazy? This discussion about the question (!) of whether Big5 is a character set is starting to make me feel like Alice in Wonderland. I wrote: > > You mean Big5 users are (perhaps) using a multilingual > > GB, CNS, and JIS environment, without even knowing it? Although you > > wrote a smiley , I think you really do believe this. Incredible! Handa replied: > You wrote some Big5 users were reading fj.* news groupd with > Big5. Doesn't it mean they have a kind of multilingual > environment? Well, yes, Big5 contains various alphabets and symbols that can be used to express various languages, not only Chinese but also Japanese, English, Russian, etc, so in this sense Big5 is multilingual. (So is ISO-8859-1, which can express English, French, Spanish, German, ...) And, yes, it is true that some Japanese fj.* newsgroups are mirrored into Big5, so that Big5 users can read them. But, in my view, these Big5 users still cannot be said to have a mixed-character-set environment. In my view, they are still using only one character set, Big5. Of course I recognize that your view is very different, because according to you Big5 is not a character set at all. > With this understanding, we can even conclude that there > exist a big character set (ASCII-BIG5) which contains all > characters in ASCII and BIG5. How do you think? I don't agree. In my view, ASCII is a character set, Big5 is a character set, but ASCII+Big5 is not what would normally be called a character set, and neither is ASCII+CNS+GB+JIS. Part of the normal concept of "character set" is that the characters in the set are grouped together by common agreement for purposes of communication. Big5 has this property, of course. I think that you should be able to appreciate this viewpoint. As you well know, ISO-2022 allows for registration of character sets, but it does not say that the union of various registered character sets is yet another character set. Getting back to your idea that Big5 is not a character set, I think this idea is so strange and has so many bizarre consequences that you should reconsider it. A more sensible viewpoint, which I think you could easily appreciate, is the following. Big5 is a character set, just like the ISO-2022 registered character sets, only it does not happen to be registered with ISO-2022. In other words, the principal difference between Big5 and registered character sets such as GB, JIS, etc, is that Big5 has not (or perhaps, not yet) gone through the ISO-2022 registration process. If you take this viewpoint, I think you will not run into so many logical difficulties. You have said that your reason for not wanting to regard Big5 as a character set is the existence of vendor-specific versions of Big5. However, Ya-Wei has said that there are dozens of different vendor-specific versions of GB. And I myself know of at least one vendor-specific version of CNS. So, once again, I don't think your reasoning makes much sense. If you don't regard Big5 as a character set for this reason, then the same should apply to GB and CNS. What about JIS? Are there any vendor-specific versions of JIS? -- Steve From cyl Fri Jul 15 11:20:16 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA03843; Fri, 15 Jul 94 11:20:16 CDT Date: Fri, 15 Jul 1994 11:20:15 -0500 (CDT) From: Nelson CHIN Subject: Re: Handa says that Big5 is not a character set To: soft-authors@ifcss.org In-Reply-To: <199407151545.LAA25602@boole.math.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO for future discussion, Don't take viewpoint presentations as tools of conforming people to be like-mined, but to give a clearer understanding of how one comes up with different proposals/implementation, so do respect one another's brain processes. I've also posted a comment on acc, of how this parrallels to the iso-2022 vs unicode camps. Looking at how iso-22022 and unicode came to this stage and the consequences thereof, from both camps, towards the commercial market, should be taken a glance at, where many of the similiar types of viewpoints on this list aren't anything new under the sun. nelson On Fri, 15 Jul 1994, Stephen G Simpson wrote: > Kenichi Handa writes: > > First of all, I'm not claiming that eveyone should have the > > same view as mine as for this CHARACTER SET topic. I just > > wanted to suggest a different view of Big5 to have the > > rationale behind Handa-* understood. > > Yes. Handa-* does not support Big5, because according to you, Big5 is > not a character set and therefore cannot be coded by any coding > system. Although I don't agree with your viewpoint, I can follow some > of the steps in your reasoning, in an abstract sense. > > I'd like to point out yet another strange consequence of your > viewpoint. You say that Big5 is not a character set but rather an > encoding system for one or several character sets. What character > sets do you have in mind? I guess you have in mind a mixture of parts > of GB, CNS, JIS, ASCII, ISO-8859-*, and some private characters. From > this point of view, your mapping of Big5 into such a mixture is > actually a *decoding*. However, in the nature of things, decoding > always follows encoding, right? In other words, nothing can be > decoded until after it has been previously encoded, right? My > question is, if conversion of Big5 into GB+CNS+JIS+... is a decoding > process, then when did the original encoding process take place? Did > it take place in the brains of the Big5 users? This strikes me as yet > another point where your viewpoint is not in agreement with the facts. > > I'm only trying to understand your viewpoint, which strikes me as very > unusual and strange. > > My own viewpoint is, of course, quite different. My view (and I think > the view of most people) is that Big5 is indeed a character set. In > fact, it is an important character set which is used by millions of > people every day. For this reason, my HZ+ proposal supports the Big5 > character set by means of a simple encoding into the graphical ASCII > range. This strikes me as a very sensible thing to do. > > Does anyone else agree with me on this? Could somebody please tell me > that I'm not crazy? This discussion about the question (!) of whether > Big5 is a character set is starting to make me feel like Alice in > Wonderland. > > I wrote: > > > You mean Big5 users are (perhaps) using a multilingual > > > GB, CNS, and JIS environment, without even knowing it? Although you > > > wrote a smiley , I think you really do believe this. Incredible! > > Handa replied: > > You wrote some Big5 users were reading fj.* news groupd with > > Big5. Doesn't it mean they have a kind of multilingual > > environment? > > Well, yes, Big5 contains various alphabets and symbols that can be > used to express various languages, not only Chinese but also Japanese, > English, Russian, etc, so in this sense Big5 is multilingual. (So is > ISO-8859-1, which can express English, French, Spanish, German, ...) > And, yes, it is true that some Japanese fj.* newsgroups are mirrored > into Big5, so that Big5 users can read them. But, in my view, these > Big5 users still cannot be said to have a mixed-character-set > environment. In my view, they are still using only one character set, > Big5. Of course I recognize that your view is very different, because > according to you Big5 is not a character set at all. > > > With this understanding, we can even conclude that there > > exist a big character set (ASCII-BIG5) which contains all > > characters in ASCII and BIG5. How do you think? > > I don't agree. In my view, ASCII is a character set, Big5 is a > character set, but ASCII+Big5 is not what would normally be called a > character set, and neither is ASCII+CNS+GB+JIS. Part of the normal > concept of "character set" is that the characters in the set are > grouped together by common agreement for purposes of communication. > Big5 has this property, of course. > > I think that you should be able to appreciate this viewpoint. As you > well know, ISO-2022 allows for registration of character sets, but it > does not say that the union of various registered character sets is > yet another character set. > > Getting back to your idea that Big5 is not a character set, I think > this idea is so strange and has so many bizarre consequences that you > should reconsider it. A more sensible viewpoint, which I think you > could easily appreciate, is the following. Big5 is a character set, > just like the ISO-2022 registered character sets, only it does not > happen to be registered with ISO-2022. In other words, the principal > difference between Big5 and registered character sets such as GB, JIS, > etc, is that Big5 has not (or perhaps, not yet) gone through the > ISO-2022 registration process. If you take this viewpoint, I think > you will not run into so many logical difficulties. > > You have said that your reason for not wanting to regard Big5 as a > character set is the existence of vendor-specific versions of Big5. > However, Ya-Wei has said that there are dozens of different > vendor-specific versions of GB. And I myself know of at least one > vendor-specific version of CNS. So, once again, I don't think your > reasoning makes much sense. If you don't regard Big5 as a character > set for this reason, then the same should apply to GB and CNS. > > What about JIS? Are there any vendor-specific versions of JIS? > > -- Steve > From simpson@math.psu.edu Fri Jul 15 11:25:13 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA04033; Fri, 15 Jul 94 11:25:13 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id MAA13385; Fri, 15 Jul 1994 12:22:50 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 15 Jul 1994 12:22:48 -0400 Date: Fri, 15 Jul 1994 12:22:48 -0400 Message-Id: <199407151622.MAA25655@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: confusion about EHZ's Big5 usage model In-Reply-To: <9407150857.AA01131@hk.Eng.Sun.COM> References: <199407141932.PAA24227@boole.math.psu.edu> <9407150857.AA01131@hk.Eng.Sun.COM> Reply-To: simpson@math.psu.edu Status: RO Ricky Yeung writes: > You're wrong. EHZ doesn't "encourage" or "recommend" the conversion of > Big5 to GB/CNS/JIS. I don't think I'm wrong. Fung is one of the authors of EHZ, and Fung encouraged and recommended this, several times. In his most recent posting, Fung wrote as follows (replying to Handa): > In practice, if a user has access to BIG5->EHZ-CNS encoder, he can > post in EHZ-CNS, or similarly he can post in mixed EHZ-CNS, EHZ-GB > and EHZ-JIS as you suggested, although what you suggested is just > one of the possible mappings in general, because it is not uncommon > to find a hanzi that exists in the character sets of GB, CNS, BIG5 and JIS. > Newsgroup organizers may impose on top of EHZ additional convention > about what subsets of EHZ should be posted in which newsgroups. > > This design tries to give maximum flexibility to the user while > maintaining the stability of the EHZ spec. It consciously leaves the > decision of what subsets of EHZ should be used to the user, and the > Chinese Internet community, in view of no easy unanimous consensus > is in sight!!! In other words, Fung is saying that EHZ contains many different options for Big5 support, and one the options is conversion from Big5 into an unspecified CNS/GB/JIS mixture. Maybe you and Fung do not really want to "encourage" this ugly option, but clearly Fung is presenting it as a serious alternative for Big5 support. And it is also clear that the existence of this ugly option means that EHZ-Big5 users would need to get multilingual CNS/GB/JIS software, even if they themselves do not elect to use the EHZ-CNS-GB-JIS option. I am very uncomfortable with this aspect of EHZ. I wrote: > ... such conversion is one of the many alternative Big5 usage > models that the author of EHZ has recommended (with a straight face). Ricky writes: > Which author? I didn't say so. If you're talking about Fung Fung Lee, > I don't recall him saying that either. ... He did indeed say it. Perhaps you and Fung need to discuss this between yourselves and then post a clarification explaining exactly what you are trying to accomplish. -- Steve From simpson@math.psu.edu Fri Jul 15 17:45:42 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA20367; Fri, 15 Jul 94 17:45:42 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id SAA17678; Fri, 15 Jul 1994 18:43:21 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 15 Jul 1994 18:43:19 -0400 Date: Fri, 15 Jul 1994 18:43:19 -0400 Message-Id: <199407152243.SAA26127@boole.math.psu.edu> To: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: Re: Getting the record straight (Was Re: reply to Ricky's criticisms) In-Reply-To: <199407140747.DAA28488@leibniz.math.psu.edu> References: <199407122019.QAA17061@boole.math.psu.edu> <199407140747.DAA28488@leibniz.math.psu.edu> Reply-To: simpson@math.psu.edu Status: RO Ricky Yeung writes: > This is an obvious misconception. Just for fun, I'll give the following > analogy. Let's consider the token ">" in C. To recognize that token, > you need to look ahead. Whatever follows helps the recognition but it's > not part of the ">" token. For instance, in the expression "a>b", you > won't say "b" is part of the ">" token. Got it? :-) > > I remember someone (Handa?) once said that EHZ is "common sense", looks > like one needs some knowledge on elementary parsing first. :-) I'm not formally trained in computer science, but I know a little about parsing, etc. I guess what Ricky is trying to say with his analogy is that the escape sequences in HZ+ require one byte of look-ahead in order to parse them. This would mean that if you are going through some EHZ text and find yourself in ASCII mode and you encounter ~{, you need to look at the next byte to decide whether ~{ meant "switch into GB-mode" or something else. For instance, if you see ~{z you know that ~{ meant "switch into GB-mode", but if you see ~{~ then it meant something else. Ricky, is that what you were trying to get at? I think it's noteworthy that escape sequences in HZ+ and in other contexts (e.g. ANSI escape sequences for terminals, etc.) do not require look-ahead. If EHZ's escape sequences require it, then they are obviously more complicated. However, I don't really think they do require it. Despite what Ricky says, I think it would be possible to write a parser for EHZ that doesn't do any look-ahead. However, this might not satisfy Ricky, because it would mean letting ~{ switch you into GB-mode immediately, without any look-ahead, something that Ricky may be reluctant to allow, because of political considerations. In any case, I think my original point stands. My original point was that the structure of the escape sequences in EHZ is much more complicated than in HZ and HZ+. First, there are a lot more of them. Second, they exhibit some redundancy, because both ~{ and ~A are used to switch into GB-mode (in different contexts). Third, they have a 2-tier structure, because for example Big5 mode is a sub-mode of non-ASCII mode. Fourth, they require look-ahead (at least Ricky seems to be implying that they do). I wrote: > I backed away from my flirtation with Ricky's EHZ framework, primarily > because EHZ changed in a way that I didn't like. ... Ricky replied: > My framework DIDN'T change. Some may want to play around with words, I > just want to get the facts straight. I'm not playing with words. I think the history was that Ricky introduced his framework, then Fung fleshed out the framework with a bunch of mapping schemes and escape sequences. Fung called his proposals EHZ-* and Ricky later decided to merge his framework with Fung's stuff, using EHZ to denote both. So it is perfectly appropriate to speak as I did of "changes in EHZ". > 2. Neutrality between GB and Big5. I've been saying that EHZ is more > neutral than HZ+S because it gives equal ASCII transparency to ALL code > schemes. I refer the readers to the soft-author mail archive > (ifcss.org:/software/soft-author-discussion/9406.log) on this much > debated "political issues" and "fairness" between Simpson and me. Ricky is arguing that, from the viewpoint of ASCII transparency, EHZ is more neutral. However, ASCII transparency isn't the only issue at stake (although Ricky sometimes talks as if it were). To my mind, EHZ is not neutral, because it makes GB-mode the default non-ASCII mode. By contrast, HZ+ does not have any such thing as a default non-ASCII mode. HZ+ gives equal status to GB and Big5. In this sense, HZ+ is more neutral. > 3. "The need for a clear usage model for Big5 users". It's a pretty > vague statement. Can you clearly define your term "usage model"? Well, I'll take a shot at it. By a usage model for Big5 users I mean some guidelines that would tell them how to use EHZ, specifically how to translate Big5 into EHZ. > What's the "clear usage model for Big5 users" for HZ+S? The clear usage model for Big5 users using HZ+S is, of course, to encode Big5 into HZ+ using the very simple mapping that is the centerpiece of the HZ+ (= HZ+S) specification. As always, the specification is available for anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/hzp/hzp.doc. > What's so unclear about EHZ? What's unclear is that there are dozens or perhaps millions of different methods of translating Big5 into EHZ, and none of these methods is specified as being preferable. This is bound to lead to confusion and errors. > 4. Ease of implementation. If you're referring to the mapping > implementation, I think HZ-2 is much simpler than HZ+S. Why is that > more important than ASCII transparency? Ease of implementation is very important, because HZ+ is intended as a low-road standard which is supposed to be very easy to incorporate into existing software such as mail and news readers and editors. The success of any low-road standard depends on ease of implementation, among other factors. As to why ease of implementation is more important that maximal ASCII transparency, I don't have any strong argument here. It's just my gut feeling that maximal ASCII transparency is really a marginal issue that you are blowing way out of proportion. -- Steve From CAI@neurophys.wisc.edu Sun Jul 17 14:29:11 1994 Return-Path: Received: from neurophys.wisc.edu (mve.neurophys.wisc.edu) by ifcss.org (4.1/IFCSS-Mailer) id AA28213; Sun, 17 Jul 94 14:29:11 CDT Received: from VMSmail by neurophys.wisc.edu; Sun, 17 Jul 94 14:25 CST Message-Id: <24071714255010@neurophys.wisc.edu> Date: Sun, 17 Jul 94 14:25 CST From: CAI@neurophys.wisc.edu Subject: the origin of big5 To: soft-authors@ifcss.org X-Vms-To: IN%"soft-authors@ifcss.org" Status: O Here is the text. It is up to you to decide wether Big5 was official or not. A few notes: 1. I did not try to insert the Chinese characters in the original text, but it would be easy to guess what Chinese characters are missing from the context. 2. I personally don't think the book was well written, in the sense that the authors were too narrow-minded and pre-occupied, and it did not present a complete story. The style of writting is more like usenet articles, which I think is inappropriate for an academic book. But nevertheless, for our particular question here, i.e., wether Big5 was official, it provided some clue. cai --------------- cut here -------------- J. K. Huang & T. D. Huang: An introduction to Chinese, Japanese and Korean computing. Chapter 5 Intemal Codes 5.6 Republic of China's Big Fives [ Note: The following is a direct translation of the General Chinese Character Standard Interchange Code [2], which was announced on March 06, and published in May, 1986 by the National Science Council, the Data Processing Center of the Treasurer of the Executive Yuan, the Ministry of Education, and the Standard Bureau of the Ministry of Economics. Author's supplement and comments are attached at the end of this section.] [... standard text here ...] 5.6.5 Comments If you notice the title of this section is Republic of China's Big Fives, you might wonder what the Big Fives are . Well, the name came about because there is a total of five standards published by the same group of people, (everytime they publish something, they use a different official title to avoid ridicule ! ) within a period of five years, from September 1980 until May 1986. These five standards are: (1) February 1981,the First Draft; (2) 0ctober 1983, the General Chinese Character Standard Interchange Codes; (3) May 1984, the Big-5 Internal Code; (4) May 1984, the IBM 5550 Internal Codes; and (5) May 1986, the "new" General Chinese Character Standard Interchange Code, which was announced in March 6, 1986. The same characters have a different code in each standard ! Everytime, a standard was announced, these bureaucrats would ask computer companies and users to switch and adhere to the new standard. Sometimes, using bureaucratic threats like --- "if you don't adapt the latest standard, you would not be able to bid on the government's contracts". Five standards in five years, with possible new ones, muddling the future, caused tremendous confusion in the Republic of China. Technically, there are too many objectionable issues to list in these five standards. Let's just take the latest one as an example. First, when it was announced in March 6, 1986, the number of characters was 13,053, and there were 94 planes. But, when the official publication was released in May, 1986, only 13,051 characters and 16 planes remained. Two characters and 78 planes vanished into a blackhole of a vaporware kingdom. Second, in this standard, character sequences are arranged by the number of strokes and then by the radicals, which are less desirable. For one thing, the distribution of Chinese characters is heavily concentrated in the range between 10 to 17 strokes (more than 3,000 characters in each category), while the number of characters in others is very low, such as the 1 stroke category which has only 16 characters. It should be arranged by radicals and then by the number of strokes. Another reason is that not everyone knows the correct number of strokes for a given character. Theoretically, if, and only if, everyone knows the correct number of strokes for each character, then there are many workable solutions. But, reality is not so rosy. From time to time we hear arguments amongst the Chinese philologists about the correct character form, and the proper number of strokes for a given character. Therefore, if these experts can not make up their minds, then how can they expect the ordinary citizen to know ? The following diagram shows the stroke distribution from the Comprehensive Chinese Dictionary by Dr. Jang1, Chi2 Yun2 [5]. This dictionary contains 49,906 Chinese characters. It can easily be seen from this diagram, that more than 59% of the characters, 29,497 to be exact, are located in a range from 10 to 17 strokes. Trying to find a character in these would be like trying to find a needle in a haystack. May God have mercy on those poor souls. Third, the number of characters in this standard is too limited. If we refer back to Sections 2.2.5 and 2.2.6 of Chapter 2, 13,051 characters are only about half of what is required for a general purpose Chinese computer. An ironic example, the character Ji1, which is used in the name of one of the biggest Chinese microcomputer companies, Multitech, in Taiwan is not included in this standard. They had identified an additional 2,082 characters, but they were not included in the standard. Why not include them, since they were already identified ? We can be very sure to rule out the reason of space limitation, because there is certainly more than enough room (16 planes). Fourth, only six variants were included in these standards. This is a very short sighted decision. When a character,no matter if it is an orthographic or a variant, is used in the name of some person or place, it becomes a legal entity. No one, even the most powerful person in the world has the right to change it. Furthermore, in this standard, there are no coding provisions whatsoever to indicate the relationship between a given variant and its orthographic character. This will only cause further confusion in the Chinese language. Fifth, let's bring the following table to show how the Big Disturbances in China by the Five Tribes of Mongol: Date 1981/2 1982/7 1983/10 1984/5 1986/3 1988/1 Name (1) (2) (3) (4) (5) (6) 031F 4C50 32F6 A4A4 4463 92E4 36AB 6675 BlAE B5D8 615E A17A 05C1 4E4A 39EF A5C1 4661 93E0 273D 5F54 A13B BOEA 594F 9D6C (1) Chinese Information Interchange Standard Code (first draft) (2) Chinese Information Interchange Standard Code (volume I) (3) General Chinese Character Standard Interchange Code (4) Big Five Code (5) "New" General Chinese Character Standard Interchange Code (6) Taipei Software Association Code Note: The Taipei Software Association Code is the latest Chinese character code standard proposed by the Association of Taipei Computer Companies, with active participation and supports from the Institute for Information Industry. >From this table, we can see that these four characters, which are the name of the Republic of China, have six different sets of interchange codes. We need yet another set of interchange code to communicate to each other ! What kind of mad joke this mess is ? Last but not least, this standard suffers the most, in the area of encompassing all Chinese characters. There are no provisions at all for containing Japanese, Korean, or even simplified characters. Afterall, these are Chinese characters. Its narrow-minded design will cause this to be another one of many incompatible standards, like the JISC6226, or the GB2312-80. Using it will not help, but will only manifest itself into a greater headache. Now we rest our case. From simpson@math.psu.edu Mon Jul 18 16:56:05 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA15744; Mon, 18 Jul 94 16:56:05 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id RAA07974; Mon, 18 Jul 1994 17:53:29 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Mon, 18 Jul 1994 17:53:27 -0400 Date: Mon, 18 Jul 1994 17:53:27 -0400 Message-Id: <199407182153.RAA05398@boole.math.psu.edu> To: mduerst@ifi.unizh.ch (Martin J. Duerst) Cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: registering Big5 Newsgroups: alt.chinese.computing In-Reply-To: <1994Jul14.175822.1168@ifi.unizh.ch> References: <199407131943.PAA23605@leibniz.math.psu.edu> <199407132042.PAA09096@news.cs.utexas.edu> <1994Jul14.175822.1168@ifi.unizh.ch> Reply-To: simpson@math.psu.edu Status: O Martin J. Duerst writes: > Well, I will try to tell you how the standards community sees these terms. > "character set" is just what it says, a set of characters. I never saw > somebody explicitly disallow duplication, but this wouldn't make much > sense anyway in this context. A different term, "charset", is usually > used to denote the character set and an encoding of it, i.e. an assignement > of a number to each of these characters. The term charset is also restricted > in that all the characters must be coded with the same number of bits. > (this is just from the X11R5 book by O'Reilly & Associates) > > In my oppinion, it is therefore very well possible to speak about > Big5 as a character set, denoting the set of those characters that > can be transmitted with Big5. Whether this includes the ASCII portion or > not may depend on circumstances. If we speek about the encoding of Big5, > then it makes sense to view it as two separate character sets, one for > Hanzi and one for ASCII, or even three, distinguishing the two Hanzi > parts. > > By the way, I do not know whether there is an ISO-2022 committee now, > there probably was some at some time, but with a different name. > However, this committee was never responsible to include (let even > define) GB or JIS or CNS or whatever. ISO-2022 is an open standard > and only defines global meanings for the escape sequences (e.g. > which group of sequences is used for single byte charsets, which > group for double byte charsets, and so on). Another standard, ISO-2375, > defines how an application to register a character set has to be > made. Quoting directly from ISO-2022-1986 (E), Annex A.1: > "Registration provides an identification for a character set but > implies nothing about its status; it may or may not be part of > an international or a national standard, or of an application-oriented > standard." > The registration authority designed by ISO is ECMA, the European > Computer Manufacturers Association, located in Geneva, Switzerland. > > So my conclusion is: > a) even if there are no ISO-2022 escape sequences for Big5, Big5 > is a character set. In technical discussions, it may > be preferable to indicate what exactly you mean when speaking > about Big5. > b) even if Big5 may not be an official standard, it can be registered > without problems with ECMA to get the necessary escape sequences. > > If anybody thinks that registering it would be something desirable > (at least for some users/applications), I am ready to try to help > with the application. > Dear Martin, Given the popularity of the Big5 character set, registering it seems like an excellent idea. And thank you very much for offering to help. However, I'm not sure who is the right person to take the lead here. I would certainly feel awkward. On the other hand, I have gathered some precise information on the ETen version of Big5 which serves as a defacto standard, and my HZ+ proposal defines a very simple mapping of Big5 into the 2-byte graphical ASCII code space (0x2121-7E7E) which makes it completely suitable for ISO-2022. What do you think? Ideally, the task of registering Big5 should be undertaken by a consortium of software and hardware companies that support Big5 in their products. Such a consortium could include ETen, Microsoft, Apple, IBM, .... Does anybody know why this has not been done? -- Steve From xiaofei Mon Jul 18 18:14:14 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA19118; Mon, 18 Jul 94 18:14:14 CDT Date: Mon, 18 Jul 94 18:14:14 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9407182314.AA19118@ifcss.org> To: soft-authors@ifcss.org Subject: MS window authors, please help Cc: xiaofei Status: O Hello, This message only concerns with MS window authors. If you are not a MS window author/user, please skip the message. Sorry for the trouble. As ms-win directory is getting larger and larger, I am going to split it into different directories following conventions of the other directories. Here is the plan. utils: general non-chinese related utils chinese-utils: chinese related utils viewer: editor: networking: convert: print: chinese-sys: game: input: input method dict: dictionaries english/chinese misc: or other directories which warrant creation The problem is I am not a MS window user, so instead of reading the readme's and struggle to figure out what they mean, I take the easy/lazy way, why do you tell me ( not the list ) what directory you program belongs to? And I will make the change accordingly. And in the futhure, please specify subdirectories if you submit new softwares. Thank you for help. From cyl Tue Jul 19 10:05:46 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA18980; Tue, 19 Jul 94 10:05:46 CDT Date: Tue, 19 Jul 1994 10:05:45 -0500 (CDT) From: Nelson CHIN Subject: HBF draft subdirectory To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO HBF v1.1 draft subdirectory is at ifcss.org:/software/fonts/hbf-discussions/draft all sections and appendixes are in individual files. all references to X11R5 is changed to X11R6, and the xlfd and bdf .ms files are there for your references. all references to HBF v1.0 is changed to v1.1 Ross suggested WWW hypertext version. We'll do that once the revision is completed, and maybe link the document to some examples of the HBF font files/implementations at ifcss.org:/software/fonts if you like to work on a particular section or comments, please email me. changes to the draft is in ChangeLog file and things requiring discussion can take place in this list. Nelson From rap@doc.ic.ac.uk Tue Jul 19 12:18:17 1994 Return-Path: Received: from santos.doc.ic.ac.uk ([146.169.2.42]) by ifcss.org (4.1/IFCSS-Mailer) id AA24447; Tue, 19 Jul 94 12:18:17 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qQIlL-00070oC; Tue, 19 Jul 94 18:15 BST Message-Id: Date: Tue, 19 Jul 94 18:15 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF draft subdirectory Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O Nelson CHIN writes: > HBF v1.1 draft subdirectory is at > ifcss.org:/software/fonts/hbf-discussions/draft > changes to the draft is in ChangeLog file and things requiring discussion > can take place in this list. I don't think the main text, describing the file format, needs any essential changes (unless someone wants to cover 3-byte codes). It just needs clarification on a few points, and correction of some minor errors. Werner Lemberg wrote: > o the standard lacks a detailed description of the relation between > HBF_BYTE_2_RANGE and HBF_CODE_RANGE. At the beginning of the > document (section 2.1) it is vaguely mentioned the term "linearized > into the byte sequence", but I think a small diagram could help > enormously: > > e.g. for Big 5: > > the glyphs in the bitmap file SPCFONT.24 > are linearly ordered starting at position 0 in the following manner: > > 0xA140 0xA141 ... 0xA17E 0xA1A1 0xA1A2 ... 0xA1FE 0xA240 ... > > etc. > > This would clarify that HBF_BYTE_2_RANGE not only indicates > allowed code values, but that there are no gaps in the bitmap font. > > o HBF should allow JIS xxxx, KS for valid HBF_CODE_SCHEME. IMHO the > format of the bitmap fonts are identical Let's add JISX0208 and KSC5601 as valid HBF_CODE_SCHEMEs. Also: The "SIZE" entry is required by BDF, but omitted from the grammar (though it appears in the second example). Should it be optional or mandatory? The text Unicode vendor v1.1 -- not simply "Unicode"; use the specific version "v1.1" supplied by "vendor". Unicode is still evolving and thus different versions exist. is wrong: v1.1 should come first; vendor extensions of it may come later. I suggest that the relevant part of the grammar be changed to 'HBF_CODE_SCHEME' hanziCodeSchemeName { unquotedString } EOLN The COPYRIGHT entry is described as referring to the HBF file, while NOTICE is supposed to be used for copyright of the bitmaps. However, these are BDF/XLFD properties, so surely they should have the same meaning as in BDF/XLFD, namely relating to copyright of the bitmap data and the typeface respectively. Copyright of the HBF file should be in a COMMENT or some new HBF_COPYRIGHT line. HBF allows numbers to be in any integer format, while BDF requires decimal. I think the HBF form is more convenient (especially for DEFAULT_CHAR), but the difference should be noted. In my implementation (Unix, DOS and VMS but could also apply to the Mac), the bitmap file name is interpreted as if the current directory were the one containing the HBF file. Should this be stated? My implementation supports an extra keyword "sideways" on the end of HBF_CODE_RANGE lines, to cope with transposed bitmaps, but I don't think this is widely used. Is it worth adding? Is there any point in having section 4? Couldn't the references to the X documents just be done in the PROPERTIES part of section 3, and the extended example placed in an appendix? How about removing Appendix 2 (proposed API) from the standard, so it just describes the file format? From simpson@math.psu.edu Tue Jul 19 13:54:49 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA28933; Tue, 19 Jul 94 13:54:49 CDT Received: from leibniz.math.psu.edu by cnd.org (4.1/4.7) id AA29166; Tue, 19 Jul 94 11:52:49 PDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id OAA15113; Tue, 19 Jul 1994 14:45:09 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Tue, 19 Jul 1994 14:45:07 -0400 Date: Tue, 19 Jul 1994 14:45:07 -0400 Message-Id: <199407191845.OAA07424@boole.math.psu.edu> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: Re: registering Big5 In-Reply-To: <1994Jul19.164823.758@ifi.unizh.ch> References: <1994Jul14.175822.1168@ifi.unizh.ch> <199407182154.QAA16303@news.cs.utexas.edu> <1994Jul19.164823.758@ifi.unizh.ch> Reply-To: simpson@math.psu.edu Status: O Martin J. Duerst writes: > Nice that somebody has taken up this idea. I have investigated a > little further and found out that a so-called sponsoring authority > is necessary for registration. I still have to find out who > can qualify as a sponsoring authority. I will do so in some > weeks, when the responsible at ECMA has returned from his > holidays. > I do not know whether I feel right, but if there is a need, and > I can be of help, I do not see any problem. The only problem > may be that there are some political aspects involved, e.g. > the institution in Taiwan responsible for standardisation > not being a member of ISO (but I am only speculating about this point). Any further information that you can provide about these aspects would be of great interest. Since planes 1 and 2 of CNS-11643 are already registered, there must be at least one agency in Taiwan that is qualified as a sponsoring authority. However, as Yidao Cai's excerpt from Huang & Huang illustrates, there are definitely some political problems here, in that the relevant agencies have shown themselves to be out of touch with the needs of computer users. > Concerning the exact details, the mappings of the two blocks > of Hanzi (+ maybe other stuff) is pretty straightforward. > For the upper block (fully filled as to what I know; my only > source is Ken Lunde's "Japanese Information Processing"), > this works as in JIS or KS or so, for the lower block, one > bit in two bytes has to be changed to either move it to > 0x2121-7E7E or to 0xA1A1-FEFE. Note that ISO-2022, in its full > generality, allows both variants, and a few other tricks. I'm not clear on what you mean by upper and lower block. The details of ETen Big5 and my proposed HZ+ mapping of it into 0x2121-7E7E is available for anonymous FTP at my site, ftp.math.psu.edu, /pub/simpson/chinese/hzp/hzp.doc. There has been a lot of discussion about this recently. > Regarding vendor-specific things, I think it would be easier > to do the work just for the bottom line common set. Having > differnt variants registered is too much work, and prefering > one vendor, even if this is a defacto standard, is also > not that nice. This would however not mean that the > extensions could not be used, somewhat un-officially, > in the same way as up to now (transmission works > only between systems with the same vendor extensions). I agree. The common part should be registered, but it should be done in such a way that vendor-specific extensions can be used unofficially. HZ+ accomplishes this in a very simple way. -- 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 Home phone +1 814 238-2274 E-mail simpson@math.psu.edu FAX +1 814 865-3735 World Wide Web http://www.math.psu.edu/simpson/ From shin@hermes.ee.nthu.edu.tw Wed Jul 20 12:23:22 1994 Return-Path: Received: from nthu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA14771; Wed, 20 Jul 94 12:23:22 CDT Received: from hermes.ee.nthu.edu.tw ([140.114.28.27]) by nthu.edu.tw with SMTP id <181776(1)>; Thu, 21 Jul 1994 01:27:05 +0800 Received: by hermes.ee.nthu.edu.tw (4.1/SMI-4.0/shin-1.0) id AA01471; Thu, 21 Jul 94 01:18:24 CST Date: Thu, 21 Jul 1994 15:18:24 +0800 From: shin@hermes.ee.nthu.edu.tw (Jing-Shin Chang) Message-Id: <9407201718.AA01471@hermes.ee.nthu.edu.tw> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: registering Big5: essential or not (at the present) Status: O Registering the Big5 characters as two 94x94 character sets to the ECMA seems to be exciting. In fact, I had asked Erik (Erik van der Poel, erik@porsche.visix.com) something about the ISO escape character registration information early on May. When I learned that there should be some sponsers, usually the standardization organization or govenment agencies, I decided to leave the official registration to the proper agency for such official standard stuffs. Furthermore, there are problems in putting something into official standard by non-official guys. In particular, I asked myself some questions: 1. Who, in this discussion forum, is qualified to register two 94x94 (sub)character sets for the Big5 characters (definitely, not me -^^-)? who are the sponsors? in what sponsoring sense? 2. Registering a pair of 94x94 character sets not only implies obtaining a pair of escape characters but also implies the registration of a mapping scheme (code assignment) to the ECMA. This action may be quite preemptive. Once such a pair of character sets and a particular mapping scheme is registered, I don't think the ECMA will be happy to register another for THE Big5 characters. If the computer companies and associations here find that somebody had registered a mapping scheme for them when they dicide to register their own, would they be happy? If more than two authors of the various 7-bit Big5 proposals want to register their own, would they be happy? 3. If we are registering with a mapping scheme like HZ-2, which is substantially different from the CNS coding scheme in terms of no. of chars in each subset and char order, then the ECMA people may not consider it odd when comparing it with CNS. If, on the other hand, the mapping scheme has essentially the same characters in both subsets, and has essentially the same order, though not fully identical, then why should they give such a similar mapping a special designation? why not leave these two escape characters to the other characters of another language? It is appropriate to say that the formal Big5 chars is a subset of the CNS char set; are the ECMA going to register a charset that is a subset of a fromally registered charset? 4. Does the registration of a pair of escape characters resolves the communication problems for the current purposes of the chinese.* groups? If this is not the essential problem, should we be bothered by the registration of such official escape characters (in fact, mapping scheme) right now? Is the use of a pair of user-agreed escape characters less useful for our current purposes for the chinese.* groups? 5. The CNS charset has now been expanded to more than 40K chars, and we can expect that all the character planes are very likely to be registered to the ECMA by the govenment agency and sponsers (with its 94x94 character subsets nature in dividing the character planes). Is it really necessary to create another exchange code standard in the 7-bit code space like the current many-code situation in the 8-bit code space? would the users here be happy to extend the many-code situation to the 7-bit world? Will the ECMA people be happy to allocate so many escape characters to the various 7-bit coding schemes for the Chinese people? I think it may not be the right time now to discuss the official registration of the 7-bit Big5 character set, with a specific mapping scheme, unless we can convience the potential sponsors or the goverment agency. Without doing this, we can still play around with our own (non-official) rules among the user groups. Of course, one still need to convience most people here in the lists/newsgroups for the mapping scheme if he/she want a particular mapping scheme to become the official standard in the lists/newsgroups. Shin -^^- From cyl Wed Jul 20 13:02:45 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA16785; Wed, 20 Jul 94 13:02:45 CDT Date: Wed, 20 Jul 1994 13:02:44 -0500 (CDT) From: Nelson CHIN Subject: HBF: GL vs GR, compression To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O now that X11R6 distributes GB fonts in GL encoding, should HBF do likewise or support both GL and GR encoded GB fonts? i think having an identifier about the byte size of the code is good, to support 3-byte and 1-byte fonts, and any other fonts that may be freely distributable. Can someone tell me the correct syntax? cai yidao told me compressed bitmap font files is desirable... and ross followed up and said it can be done with gzip, but gzip may not be readily available on all platforms,... what do others think? Hopefully when the ECMA General Secretary returns back to his office on the 25th, i can learn of the current status of planes 3-7 of CNS font, and would like to include that as a recognized font in HBF standard. Just for curiosity, has anyone gotten any statistics as to what % of HZ and or extended HZ code would not make it through gateways that corrupts the text as addressed by MIME? and what % of those gateways exist on the Internet? and if we want to reach chinese users behind such gateways w/o upgrading their system, 7-bitness is not enough, you'll need to restrict to only those 7-bit characters which are safe to travel uncorrupted through such gateways. Nelson From yawei@cs.indiana.edu Thu Jul 21 00:02:50 1994 Return-Path: Received: from moose.cs.indiana.edu by ifcss.org (4.1/IFCSS-Mailer) id AA11920; Thu, 21 Jul 94 00:02:50 CDT Message-Id: <9407210502.AA11920@ifcss.org> Received: by moose.cs.indiana.edu (5.65c/9.4jsm) id AA13184; Thu, 21 Jul 1994 00:00:31 -0500 Date: Thu, 21 Jul 1994 00:00:31 -0500 From: "Ya-Gui Wei" To: cyl@ifcss.org, soft-authors@ifcss.org Subject: Re: HBF: GL vs GR, compression Status: O HZ is no more subject to EBCDIC gateway corruption than ASCII text is. And when you get a piece of ASCII text that is corrupted, it is usually not a problem -- The human brain can immediately tell which character is corrupted and mentally make the correction. That's why users of IBM mainframes can still exchange e-mails with the rest of the world despite the occasional problem. The same is true for HZ. When you get a pieces of HZ mail and some characters seem out of place, your brain will almost always make the automatic correction for you. The same cannot be said of other schemes -- especially any schems that involves compression. A few corrupted characters can ruin an entire compressed file. Any ASCII character that does not appear in the EDCBIC character set is a candidate for such corruption, because there are no standard way of mapping these characters into EDCBIC. Ya-Gui From nsysu11@cc.nsysu.edu.tw Thu Jul 21 23:19:21 1994 Return-Path: Received: from cc.nsysu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA03233; Thu, 21 Jul 94 23:19:21 CDT Received: (from nsysu11@localhost) by cc.nsysu.edu.tw (8.6.9/8.6.9) id MAA05891; Fri, 22 Jul 1994 12:12:45 +0800 Date: Fri, 22 Jul 1994 11:12:16 +0800 (CST) From: Werner Lemberg Subject: Re: HBF draft subdirectory To: soft-authors@ifcss.org In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Tue, 19 Jul 1994, Ross Paterson wrote: > Nelson CHIN writes: > > HBF v1.1 draft subdirectory is at > > ifcss.org:/software/fonts/hbf-discussions/draft > > > changes to the draft is in ChangeLog file and things requiring discussion > > can take place in this list. > > I don't think the main text, describing the file format, needs any > essential changes (unless someone wants to cover 3-byte codes). It just > needs clarification on a few points, and correction of some minor errors. But it needs a grammatical touch ... perhaps somebody with English as his mothertongue could do it. > > In my implementation (Unix, DOS and VMS but could also apply to the > Mac), the bitmap file name is interpreted as if the current directory > were the one containing the HBF file. Should this be stated? IMHO yes. > > My implementation supports an extra keyword "sideways" on the end of > HBF_CODE_RANGE lines, to cope with transposed bitmaps, but I don't think > this is widely used. Is it worth adding? You have already implemented it, thus yes :-) > > Is there any point in having section 4? Couldn't the references to the > X documents just be done in the PROPERTIES part of section 3, and the > extended example placed in an appendix? A good idea. > > How about removing Appendix 2 (proposed API) from the standard, so it > just describes the file format? > It could be stated that an implementation (yours :-) is available electronically at ifcss.org From cyl Fri Jul 22 02:57:47 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA10205; Fri, 22 Jul 94 02:57:47 CDT Date: Fri, 22 Jul 1994 02:57:46 -0500 (CDT) From: Nelson CHIN Subject: HBF draft To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O >From nsysu11@cc.nsysu.edu.tw Thu Jul 21 23:19:21 1994 >Date: Fri, 22 Jul 1994 11:12:16 +0800 (CST) >From: Werner Lemberg >Subject: Re: HBF draft subdirectory > >On Tue, 19 Jul 1994, Ross Paterson wrote: > >> HBF_CODE_RANGE lines, to cope with transposed bitmaps, but I don't think >> this is widely used. Is it worth adding? > >You have already implemented it, thus yes :-) to take one step further, just adopt the rest of the extra implementation here's an excerpt from the readme file, but where should i put this: The code appears to work under Unix, MSDOS and VMS. It has a few features not specified in the standard: - if a relative HBF filename is supplied to hbfOpen/HBF_OpenFont, and the environment variable HBFPATH is set, the filename is searched for relative to the directories listed in HBFPATH (separated by colons in Unix, semi-colons in MSDOS, commas in VMS). - if bitmap filenames in the HBF file are relative, they are taken to be relative to the directory containing the HBF file. - if the word "sideways" is appended to an HBF_CODE_RANGE line, those bitmaps are transposed on input. - there are 2 extra functions hbfForEach() and hbfFileName() that have proved useful. > >It could be stated that an implementation (yours :-) is available >electronically at ifcss.org added into the draft in section 1. From rap@doc.ic.ac.uk Fri Jul 22 07:05:31 1994 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA15795; Fri, 22 Jul 94 07:05:31 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qRJJj-00070kC; Fri, 22 Jul 94 13:03 BST Message-Id: Date: Fri, 22 Jul 94 13:03 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O Nelson CHIN writes: > to take one step further, just adopt the rest of the extra implementation > here's an excerpt from the readme file, but where should i put this: > The code appears to work under Unix, MSDOS and VMS. It has a few features > not specified in the standard: > - if a relative HBF filename is supplied to hbfOpen/HBF_OpenFont, and > the environment variable HBFPATH is set, the filename is searched for > relative to the directories listed in HBFPATH (separated by colons in > Unix, semi-colons in MSDOS, commas in VMS). > - if bitmap filenames in the HBF file are relative, they are taken to > be relative to the directory containing the HBF file. > - if the word "sideways" is appended to an HBF_CODE_RANGE line, those > bitmaps are transposed on input. > - there are 2 extra functions hbfForEach() and hbfFileName() that have > proved useful. Only the second and third are related to the file format. As to whether they should be included (presumably under HBF_CODE_RANGE), the question is whether implementors should be required to support them. Also, to reflect the fact that this format is useful for any font of uniform bitmaps, perhaps "hanzi" should be changed to "character" in many places. From cyl Fri Jul 22 11:30:16 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA25952; Fri, 22 Jul 94 11:30:16 CDT Date: Fri, 22 Jul 1994 11:30:15 -0500 (CDT) From: Nelson CHIN Subject: Re: HBF draft To: Ross Paterson Cc: soft-authors@ifcss.org In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O On Fri, 22 Jul 1994, Ross Paterson wrote: > > - if bitmap filenames in the HBF file are relative, they are taken to > > be relative to the directory containing the HBF file. should this be overrided if HBFPATH environment is defined or should this override the HBFPATH environment? this should be specified, so implementors know how such relative paths should behave given that HBFPATH environment is set. > > - if the word "sideways" is appended to an HBF_CODE_RANGE line, those > > bitmaps are transposed on input. i think those implementing HBF v1.1 should make this non-optional, just grab the src from your HBF c interface package. > > Also, to reflect the fact that this format is useful for any font of > uniform bitmaps, perhaps "hanzi" should be changed to "character" in > many places. > yep, HBF can deal more than just GB or BIG5, so i'll do the changes. for those of you who like proofreading, please do.. nelson From CAI%MVF.DecNet@wigate.nic.wisc.edu Fri Jul 22 11:40:42 1994 Return-Path: Received: from vms.macc.wisc.edu by ifcss.org (4.1/IFCSS-Mailer) id AA26506; Fri, 22 Jul 94 11:40:42 CDT Received: from VMSmail by wircs1.DecNet; Fri, 22 Jul 94 11:38 CDT Message-Id: <24072211382230@wircs1.DecNet> Date: Fri, 22 Jul 94 11:38 CDT From: CAI%MVF.DecNet@wigate.nic.wisc.edu Subject: HBF revision: questions of concern To: soft-authors@ifcss.org X-Vms-To: WIRCS1::IN%"soft-authors@ifcss.org" Status: O This is a reply to several public and private mails. The quatations may not be exact (i.e. maybe Nelson wrote what I thought Ross wrote). >From: IN%"rap@doc.ic.ac.UK" "Ross Paterson" 19-JUL-1994 12:35:33.19 In my implementation (Unix, DOS and VMS but could also apply to the Mac), the bitmap file name is interpreted as if the current directory were the one containing the HBF file. Should this be stated? ----- No. I think this is implementation details and the HBF specification should not cover these. My implementation supports an extra keyword "sideways" on the end of HBF_CODE_RANGE lines, to cope with transposed bitmaps, but I don't think this is widely used. Is it worth adding? ------- Probably it is better leave it as it is, since there is no need to have two sets of bitmaps having the exact content, only with bitmap transposed. By supporting it "privately", it shows these transposed bitmaps are discouraged, yet gives users the convienience. And in practice, there are not so many transposed bitmaps. How about using "transposed" instead of "sideways" ? I think "transposed" refects the relation better. How about removing Appendix 2 (proposed API) from the standard, so it just describes the file format? ------- Maybe we can state that it is NOT part of the specification and keep it there. ...... Cai Yidao writes: > ------- I would like to see font compression be somehow included, but I don't > know if it is possible technically, since compression distroys the bases of > hbf, i.e. the bitmap data for all characters have the same length. Ross replied: I can see how to do it under Unix, but it would mean forcing a particular implementation. Currently an HBF implementation can either read the whole bitmap file into memory, or it can read bitmaps as requested (that's what my implementation does). Under Unix it would be easy enough to to pipe a gzipped bitmap file through gzcat while reading it, if you settled for the first approach -- might use quite a bit of memory though. I think a private compression scheme would be too much trouble. Ross ----- I don't have better ideas. >From: IN%"cyl@ifcss.ORG" "Nelson CHIN" 20-JUL-1994 13:06:55.11 now that X11R6 distributes GB fonts in GL encoding, should HBF do likewise or support both GL and GR encoded GB fonts? ------ It's no harm to support both and this is actually allowed by the present version. The JIS fonts at ifcss.org are in GL and I wonder how Ross's implementation supported it. The question is wether an entry is needed to indicate GL or GR, but an implementation can always find it out by checking the byte2 range or the range in HBF_CODE_RANGE lines. I favor the later since we don't need to change anything at all. BTW, what exactly do GL and GR stand for? i think having an identifier about the byte size of the code is good, to support 3-byte and 1-byte fonts, and any other fonts that may be freely distributable. Can someone tell me the correct syntax? ------- For 1-byte fonts, there is no HBF_BYTE2_RANGES, for 3-byte fonts, add HBF_BYTE2_RANGES. These were discussed before by F F Lee when we talked about future revisions in this aspect. >It could be stated that an implementation (yours :-) is available >electronically at ifcss.org added into the draft in section 1. ------ This site-specific information should NOT constitute part of a specification/standard. It could appear in appendix though, making it clear the appendix is not part of the specification. Also, to reflect the fact that this format is useful for any font of uniform bitmaps, perhaps "hanzi" should be changed to "character" in many places. -------- Right now we may keep the name as it is and make a note that it could cover all uniform bitmaps, not just Hanzi in Chinese, Japanese and Korean. Otherwise we have to change "HBF" to something else, which we could not afford to at the moment (for gaining support and the trouble of changing current softwares/HBF files) cai From rap@doc.ic.ac.uk Fri Jul 22 12:05:46 1994 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA27699; Fri, 22 Jul 94 12:05:46 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qRO0E-00070kC; Fri, 22 Jul 94 18:03 BST Message-Id: Date: Fri, 22 Jul 94 18:03 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O Nelson CHIN writes: > [hbf/README:] > > - if bitmap filenames in the HBF file are relative, they are taken to > > be relative to the directory containing the HBF file. > should this be overrided if HBFPATH environment is defined > or should this override the HBFPATH environment? this should be > specified, so implementors know how such relative paths should behave > given that HBFPATH environment is set. In my implementation: - HBFPATH only says where to look for HBF files, not bitmap files. - The meaning of a relative bitmap file name is determined by the location of the HBF file, independent of how you found it or of whether HBFPATH is set. That way, if I have some working HBF files, other people can add the directory containing them to their HBFPATHs, or can refer to the HBF files by their full names, and the files will work in the same way they do for me. Also, the bitmap files can be placed in other directories, not necessarily on the HBFPATH. If we're thinking about changes, how about making CHARS optional? It's only there for BDF compatability, is a nuisance to get right, and could be computed by hbftobdf. From cyl Fri Jul 22 12:31:25 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA28743; Fri, 22 Jul 94 12:31:25 CDT Date: Fri, 22 Jul 1994 12:31:22 -0500 (CDT) From: Nelson CHIN Sender: Nelson CHIN Reply-To: Nelson CHIN Subject: Re: HBF revision: questions of concern To: CAI%MVF.DecNet@wigate.nic.wisc.edu Cc: soft-authors@ifcss.org In-Reply-To: <24072211382230@wircs1.DecNet> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O On Fri, 22 Jul 1994 CAI%MVF.DecNet@wigate.nic.wisc.edu wrote: > > ----- No. I think this is implementation details and the HBF specification > should not cover these. ok, so any implementation mentioned or refered to is not part of the HBF STandard, is that correct? but i do think that some agreed upon HBF implementation is valuable. > How about removing Appendix 2 (proposed API) from the standard, so it > just describes the file format? > > ------- Maybe we can state that it is NOT part of the specification and keep it > there. Should appendixes in general be considered as part of a standard or not? Right now the current draft has a sample full HBF file as Appendix 2. i can put the proposed API back in, or we can used Rosses implementaton as reference instead. > >It could be stated that an implementation (yours :-) is available > >electronically at ifcss.org > added into the draft in section 1. > > ------ This site-specific information should NOT constitute part of a > specification/standard. It could appear in appendix though, making > it clear the appendix is not part of the specification. at the end of section 1, there's a list of references, for BDF and XLFD and i just added Ross's as reference 3. What i can do is move the reference section into it's own section as Endnotes.. also keep in mind that a hypertext version for WWW will be made availabe, and thus any mention of sample implementation or BDF or XLFD or specific fonts or character sets, or other information will be link to the actual source site, so interested parties can go to the actual file for more information. > Also, to reflect the fact that this format is useful for any font of > uniform bitmaps, perhaps "hanzi" should be changed to "character" in > many places. > > -------- Right now we may keep the name as it is and make a note that it > could cover all uniform bitmaps, not just Hanzi in Chinese, Japanese > and Korean. Otherwise we have to change "HBF" to something else, > which we could not afford to at the moment (for gaining support > and the trouble of changing current softwares/HBF files) > > cai > From rap@doc.ic.ac.uk Fri Jul 22 13:15:13 1994 Return-Path: Received: from santos.doc.ic.ac.uk by ifcss.org (4.1/IFCSS-Mailer) id AA00899; Fri, 22 Jul 94 13:15:13 CDT Received: by santos.doc.ic.ac.uk (Smail3.1.28.1 #7) id m0qRP5X-00070kC; Fri, 22 Jul 94 19:12 BST Message-Id: Date: Fri, 22 Jul 94 19:12 BST From: Ross Paterson To: soft-authors@ifcss.org Subject: Re: HBF revision: questions of concern Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Status: O CAI%MVF.DecNet@wigate.nic.wisc.edu writes: Ross> In my implementation (Unix, DOS and VMS but could also apply to the Ross> Mac), the bitmap file name is interpreted as if the current directory Ross> were the one containing the HBF file. Should this be stated? > ----- No. I think this is implementation details and the HBF specification > should not cover these. That's certainly true of HBFPATH, and HBF file naming conventions, but this relates to the contents of HBF files. I think it's worth at least a note in the spec, even to say it's not mandated, but common practice. (There's a whole paragraph on HBF file naming.) Ross> My implementation supports an extra keyword "sideways" on the end of Ross> HBF_CODE_RANGE lines, to cope with transposed bitmaps, but I don't think Ross> this is widely used. Is it worth adding? > ------- Probably it is better leave it as it is, since there is no need > to have two sets of bitmaps having the exact content, only with > bitmap transposed. By supporting it "privately", it shows these > transposed bitmaps are discouraged, yet gives users the convienience. > And in practice, there are not so many transposed bitmaps. That sounds fine to me. > How about using "transposed" instead of "sideways" ? I think > "transposed" refects the relation better. OK, you can have both. Ross> now that X11R6 distributes GB fonts in GL encoding, should HBF do Ross> likewise or support both GL and GR encoded GB fonts? > ------ It's no harm to support both and this is actually allowed by > the present version. The JIS fonts at ifcss.org are in GL and > I wonder how Ross's implementation supported it. The question > is wether an entry is needed to indicate GL or GR, but an > implementation can always find it out by checking the byte2 > range or the range in HBF_CODE_RANGE lines. I favor the later > since we don't need to change anything at all. I think this belongs in the program using the HBF routines -- It should always map to GL before looking up the character. It will be easiest if all HBF files for GB, JIS and KSC use GL coding. > BTW, what exactly do GL and GR stand for? Graphic Left (0x21-0x7E) and Graphic Right (0xA1-0xFE). Ross> Also, to reflect the fact that this format is useful for any font of Ross> uniform bitmaps, perhaps "hanzi" should be changed to "character" in Ross> many places. > -------- Right now we may keep the name as it is and make a note that it > could cover all uniform bitmaps, not just Hanzi in Chinese, Japanese > and Korean. Otherwise we have to change "HBF" to something else, > which we could not afford to at the moment (for gaining support > and the trouble of changing current softwares/HBF files) The name HBF, yes, but the text of the spec has lots of references to "hanzi" that could be changed to "character" without hurting anything. From CAI%MVF.DecNet@wigate.nic.wisc.edu Fri Jul 22 22:43:39 1994 Return-Path: Received: from vms.macc.wisc.edu by ifcss.org (4.1/IFCSS-Mailer) id AA22217; Fri, 22 Jul 94 22:43:39 CDT Received: from VMSmail by wircs1.DecNet; Fri, 22 Jul 94 22:41 CDT Message-Id: <24072222411933@wircs1.DecNet> Date: Fri, 22 Jul 94 22:41 CDT From: CAI%MVF.DecNet@wigate.nic.wisc.edu Subject: hbf To: soft-authors@ifcss.org X-Vms-To: WIRCS1::IN%"soft-authors@ifcss.org" Status: RO >From: IN%"CAI%MVF.DecNet@wigate.nic.Wisc.EDU" 22-JUL-1994 11:48:23.71 Subj: HBF revision: questions of concern ------- For 1-byte fonts, there is no HBF_BYTE2_RANGES, for 3-byte fonts, add HBF_BYTE2_RANGES. These were discussed before by F F Lee ------------------ should be "HBF_BYTE3_RANGES". Sorry for this mistake. >From: IN%"rap@doc.ic.ac.UK" "Ross Paterson" 22-JUL-1994 13:19:06.17 That's certainly true of HBFPATH, and HBF file naming conventions, but this relates to the contents of HBF files. I think it's worth at least a note in the spec, even to say it's not mandated, but common practice. ------- That's ok with me. I think this belongs in the program using the HBF routines -- It should always map to GL before looking up the character. It will be easiest if all HBF files for GB, JIS and KSC use GL coding. -------- If we have to choose one from GL and GR, I think GR is better for the following reasons: 1. Most hbf files so far are in GR, only some JIS and KSC hbf files are in GL,and there are not many users of them at present. If we change to GL, not only most programs need to be changed, users need to get their hbf files again. 2. Mapping to GL and mapping to GR are equally troublesome from implementation point of view. 3. For Big5, which has two byte2 ranges, mapping to GL would not work. The name HBF, yes, but the text of the spec has lots of references to "hanzi" that could be changed to "character" without hurting anything. ------- That's fine. cai cai@neurophys.wisc.edu From cyl Mon Jul 25 09:05:11 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA00416; Mon, 25 Jul 94 09:05:11 CDT Date: Mon, 25 Jul 1994 09:05:09 -0500 (CDT) From: Nelson CHIN Subject: hzbanner Ver0.9->0.91 patch (fwd);problem w/HBF To: yasuoka@kudpc.kyoto-u.ac.jp Cc: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O thanx for addressing the problem w/HBF.. we're revising HBF right now and hopefully it'll solve it, which is discussed on the soft-authors mailing list. you're welcomed to join the list, just email me. the log for the list is in ifcss.org:/software/fonts/hbf-discussion and /software/soft-authors-discussion, nelson ---------- Forwarded message ---------- Date: Mon, 25 Jul 94 16:55:18 +0900 >From: Koichi Yasuoka To: cyl@ifcss.org Cc: yasuoka@kudpc.kyoto-u.ac.jp Subject: hzbanner Ver0.9->0.91 patch Enclosed patch of hzbanner Version 0.91. This patch enables you to use other BDF's bigger (or smaller) than 16x16. However, here I gave up to handle HBF's as reasons follows: 1) HBF cannot handle half-size characters. GB8565-89 includes such characters at 0x2a21 to 0x2b3f. 2) The way to find bitmapFileName in a program is not clearly defined. For example, HBF_CODE_RANGE 0x2121-0x217f guobiao16.bin 0 does not show us where "guobiao16.bin" exists. How do we find it? In the same directory? In the current directory? Searching some paths? I think 1st one is a problem for HBF's definition itself. How do you think? Well, edit the "Makefile" to use a font other than "guobiao16.bdf". Koichi Yasuoka -------- cut here ------- cut here ------- cut here ------- cut here ------- *** Makefile.old Thu Jul 21 10:36:09 1994 --- Makefile Mon Jul 25 15:50:16 1994 *************** *** 17,24 **** font: fonts.alias ! font1a.c font1b.c font1c.c: guobiao16.bdf bdf2c ! awk -f bdf2c n=1 guobiao16.bdf fonts.alias: fonts.dir sed -e 1d -e 's/^\([^.]*\)\.$(FONTSUFFIX)/\1/' fonts.dir > fonts.alias --- 17,24 ---- font: fonts.alias ! font1a.c font1b.c font1c.c font1.h: guobiao16.bdf bdf2c ! awk -f bdf2c n=1 guobiao16.bdf > font1.h fonts.alias: fonts.dir sed -e 1d -e 's/^\([^.]*\)\.$(FONTSUFFIX)/\1/' fonts.dir > fonts.alias *************** *** 34,36 **** --- 34,38 ---- veryclean muchclean: rm -f hzbanner font*.c *.o guobiaoR16.bdf *.$(FONTSUFFIX) fonts.* core + + hzbanner.o: font1.h *** bdf2c.old Wed Jul 20 00:16:23 1994 --- bdf2c Mon Jul 25 14:29:14 1994 *************** *** 6,11 **** --- 6,26 ---- printf("#include \n")>fc; b=0; } + $1=="FONTBOUNDINGBOX"{ + width=$2; + height=$3; + bytes=int((width+7)/8)*height; + printf("#define FONT%dWIDTH %d\n",n,width); + printf("#define FONT%dHEIGHT %d\n",n,height); + printf("#define FONT%dBYTES %d\n",n,bytes); + pad=""; + for(i=0;ifp; if(fp!=fc) ! printf("extern unsigned short f%d_%02d[];\n",n,e/256-32)>fc; } } - printf(" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0")>fp; if(e%256==126){ ! printf("\n};\n")>fp; e+=163; } else{ ! printf(",\n")>fp; e++; } } if(e%256==33){ fp=sprintf("font%d%c.c",n,e/8192+96); ! printf("unsigned short f%d_%02d[]={\n",n,e/256-32)>fp; if(fp!=fc) ! printf("extern unsigned short f%d_%02d[];\n",n,e/256-32)>fc; } } ! b==16{ if(e%256==126){ ! printf("0x%s\n};\n",$1)>fp; e+=163; } else{ ! printf("0x%s,\n",$1)>fp; e++; } b=0; } b>0{ ! printf("0x%s,",$1)>fp; ! b++; } $1=="BITMAP"{ b=1; --- 31,96 ---- continue; } else{ ! printf("unsigned char f%d_%02d[]={\n",n,e/256-32)>fp; if(fp!=fc) ! printf("extern unsigned char f%d_%02d[];\n",n,e/256-32)>fc; } } if(e%256==126){ ! printf("%s\n};\n",nullchar)>fp; e+=163; } else{ ! printf("%s,\n",nullchar)>fp; e++; } } if(e%256==33){ fp=sprintf("font%d%c.c",n,e/8192+96); ! printf("unsigned char f%d_%02d[]={\n",n,e/256-32)>fp; if(fp!=fc) ! printf("extern unsigned char f%d_%02d[];\n",n,e/256-32)>fc; } } ! b>0&&b==height{ ! if($1=="ENDCHAR") ! t=pad; ! else ! t=$1 pad; ! for(i=8;ifp; if(e%256==126){ ! printf("0x%s\n};\n",substr(t,i/4-1,2))>fp; e+=163; } else{ ! printf("0x%s,\n",substr(t,i/4-1,2))>fp; e++; } b=0; } b>0{ ! if($1=="ENDCHAR"){ ! while(bfp; ! b++; ! } ! if(e%256==126){ ! printf("%s\n};\n",nullchar)>fp; ! e+=163; ! } ! else{ ! printf("%s,\n",nullchar)>fp; ! e++; ! } ! b=0; ! } ! else{ ! t=$1 pad; ! for(i=0;ifp; ! b++; ! } } $1=="BITMAP"{ b=1; *************** *** 59,75 **** } $1=="ENDFONT"{ while(e%256!=33){ - printf(" 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0")>fp; if(e%256==126){ ! printf("\n};\n")>fp; e+=163; } else{ ! printf(",\n")>fp; e++; } } ! printf("unsigned short *font%d[]={\n",n)>fc; for(i=1;i<94;i++){ if(i>e/256-33) printf(" NULL,\n")>fc; --- 98,113 ---- } $1=="ENDFONT"{ while(e%256!=33){ if(e%256==126){ ! printf("%s\n};\n",nullchar)>fp; e+=163; } else{ ! printf("%s,\n",nullchar)>fp; e++; } } ! printf("unsigned char *font%d[]={\n",n)>fc; for(i=1;i<94;i++){ if(i>e/256-33) printf(" NULL,\n")>fc; *** guobiao16.bdf.old Wed Jul 20 17:41:26 1994 --- guobiao16.bdf Mon Jul 25 15:30:36 1994 *************** *** 1,6 **** STARTFONT 2.1 COMMENT ! COMMENT Extended GuoBiao Font (GB2312-80 + GB8565-89) Version 0.9 COMMENT COMMENT GB2312-80 Character Design COMMENT The Institute of Software, Academia Sinica, Beijing, China --- 1,6 ---- STARTFONT 2.1 COMMENT ! COMMENT Extended GuoBiao Font (GB2312-80 + GB8565-89) Version 0.91 COMMENT COMMENT GB2312-80 Character Design COMMENT The Institute of Software, Academia Sinica, Beijing, China *************** *** 25048,25062 **** 1936 1478 26d9 ! 439f ! 3ffe ! 07f0 ! 0630 ! 27f2 3fff ! 37f6 ! 3636 ! 37f6 ENDCHAR STARTCHAR 12-55 ENCODING 11351 --- 25048,25062 ---- 1936 1478 26d9 ! 7fff ! 0ff8 ! 0c18 ! 2ffa 3fff ! 3366 ! 3e7e ! 33f6 ! 30c6 ENDCHAR STARTCHAR 12-55 ENCODING 11351 *************** *** 25501,25513 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 4100 ! 7fff ! 5533 ! 5533 ! 55bb 7f77 ! 5177 3233 3f77 36bb --- 25501,25513 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0800 ! 08ff ! 6b33 ! 6b33 ! 6bbb 7f77 ! 3177 3233 3f77 36bb *************** *** 28146,28167 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 0000 ! 1ffc ! 1080 ! 11e0 ! 11b0 ! 1ff8 ! 1180 ! 1188 ! 1198 ! 13b0 ! 32c0 ! 3480 ! 28fc ! 30fc ! 0000 ENDCHAR STARTCHAR 14-02 ENCODING 11810 --- 28146,28167 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 1002 ! 1fff ! 1910 ! 1998 ! 1982 ! 1fff ! 1980 ! 1b44 ! 1bce ! 1acc ! 1ed8 ! 34f0 ! 38c0 ! 3182 ! 227f ! 443e ENDCHAR STARTCHAR 14-02 ENCODING 11810 *************** *** 28169,28190 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0040 ! 0040 ! 0040 3fff ! 2081 ! 2081 ! 2081 ! 2091 ! 2109 ! 2109 ! 227d ! 2fc5 ! 2005 ! 2001 ! 2001 ! 2007 ENDCHAR STARTCHAR 14-03 ENCODING 11811 --- 28169,28190 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0080 ! 01c0 ! 2182 3fff ! 3386 ! 3346 ! 3366 ! 3666 ! 3636 ! 3436 ! 3ffe ! 3c1e ! 3816 ! 3006 ! 301e ! 2004 ENDCHAR STARTCHAR 14-03 ENCODING 11811 *************** *** 28238,28259 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0400 ! 05ff ! 0410 ! 0854 ! 0852 ! 1091 ! 1911 ! 2810 ! 2810 ! 49ff ! 0810 ! 0810 ! 0810 ! 0810 ! 0810 ! 0810 ENDCHAR STARTCHAR 14-06 ENCODING 11814 --- 28238,28259 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0402 ! 0fff ! 0c30 ! 18b6 ! 30f6 ! 58b8 ! 1832 ! 1bff ! 1830 ! 1830 ! 1830 ! 1830 ! 1830 ! 1830 ! 1830 ! 1020 ENDCHAR STARTCHAR 14-06 ENCODING 11814 *************** *** 28307,28328 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 081e ! 0be4 ! 0942 ! 1221 ! 1448 ! 3190 ! 3060 ! 5184 ! 53fe ! 1022 ! 1020 ! 17ff ! 1020 ! 1050 ! 118c ! 1603 ENDCHAR STARTCHAR 14-09 ENCODING 11817 --- 28307,28328 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 041e ! 0ef4 ! 0d26 ! 18fe ! 3054 ! 5828 ! 186c ! 18fe ! 1830 ! 1864 ! 18fa ! 1830 ! 19ff ! 1878 ! 18cf ! 1306 ENDCHAR STARTCHAR 14-09 ENCODING 11817 *************** *** 28330,28351 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0800 ! 0800 ! 0ffe ! 1002 ! 1102 ! 2922 ! 4542 ! 0102 ! 1ff2 ! 0382 ! 0542 ! 0922 ! 1112 ! 2102 ! 0104 ! 0018 ENDCHAR STARTCHAR 14-10 ENCODING 11818 --- 28330,28351 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0100 ! 0380 ! 0300 ! 0602 ! 0fff ! 1d26 ! 3fb6 ! 43e6 ! 01c6 ! 0ff6 ! 0186 ! 03c6 ! 07e6 ! 09ac ! 011c ! 0008 ENDCHAR STARTCHAR 14-10 ENCODING 11818 *************** *** 28376,28397 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 7ffe ! 4002 ! 5ffa ! 0000 ! 0ff0 ! 0810 ! 0ff0 ! 0000 ! 3ffc ! 2104 ! 2104 ! 3ffc ! 2104 ! 2104 ! 3ffc ENDCHAR STARTCHAR 14-12 ENCODING 11820 --- 28376,28397 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 1002 ! 3fff ! 7006 ! 2ffc ! 0010 ! 07f8 ! 0630 ! 0630 ! 07f0 ! 1004 ! 1ffe ! 18cc ! 1ffc ! 18cc ! 1ffc ! 1008 ENDCHAR STARTCHAR 14-12 ENCODING 11820 *************** *** 28445,28466 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0080 ! 0080 1ffc ! 0080 ! 0080 ! 0080 ! 0080 7fff ! 0808 ! 0808 ! 0808 ! 3e3e ! 0808 ! 0808 ! 0f08 ! 787f ENDCHAR STARTCHAR 14-15 ENCODING 11823 --- 28445,28466 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0100 ! 0188 1ffc ! 0180 ! 0180 ! 0180 ! 0182 7fff ! 0810 ! 0c18 ! 0c18 ! 3f7e ! 0c18 ! 0c18 ! 0f19 ! 7cff ENDCHAR STARTCHAR 14-15 ENCODING 11823 *************** *** 28468,28489 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 003c ! 1fc0 ! 1000 ! 1ffe ! 1000 ! 1000 ! 17fc ! 1404 ! 1404 ! 17fc ! 1040 ! 2040 ! 27fc ! 2040 ! 4040 ! 0ffe ENDCHAR STARTCHAR 14-16 ENCODING 11824 --- 28468,28489 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0018 ! 11fc ! 1f80 ! 1802 ! 1fff ! 1a04 ! 1bfe ! 1b0c ! 1b0c ! 1bfc ! 3248 ! 3060 ! 23fc ! 4060 ! 0062 ! 0fff ENDCHAR STARTCHAR 14-16 ENCODING 11824 *************** *** 28537,28558 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 27ff ! 2401 ! 2000 ! 23fe ! 7880 ! 20e1 ! 2132 ! 264c ! 2098 ! 29a8 ! 324c ! 60ab ! 0110 ! 0060 ! 0000 ! 0000 ENDCHAR STARTCHAR 14-19 ENCODING 11827 --- 28537,28558 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0102 ! 13ff ! 1b03 ! 1afa ! 7c70 ! 18e0 ! 19a4 ! 1bb6 ! 19fc ! 18f8 ! 19bc ! 1ef4 ! 78f6 ! 21b3 ! 0272 ! 0020 ENDCHAR STARTCHAR 14-19 ENCODING 11827 *************** *** 28606,28627 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 100e ! 1070 ! 1010 ! 11ff ! 7e10 ! 14fe ! 1492 ! 14fe ! 1492 ! 14fe ! 2410 ! 24fe ! 2410 ! 25ff ! 4401 ! 43ff ENDCHAR STARTCHAR 14-22 ENCODING 11830 --- 28606,28627 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 1007 ! 1878 ! 1908 ! 7fff ! 1b08 ! 1b7f ! 1b6b ! 1b7f ! 1b6b ! 1b7f ! 1b08 ! 1b3e ! 1b0a ! 137f ! 23ff ! 41fe ENDCHAR STARTCHAR 14-22 ENCODING 11830 *************** *** 28629,28650 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 004c ! 0046 ! 0042 ! 0040 ! ffff ! 0040 ! 0040 ! 0040 0060 ! 0020 ! 0020 ! ff30 ! 0011 ! 001b ! 000e ! 0004 ENDCHAR STARTCHAR 14-23 ENCODING 11831 --- 28629,28650 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0050 ! 0068 ! 006c ! 0068 ! 3ffe 0060 ! 0060 ! 0060 ! 0060 ! 0030 ! 00b0 ! 7fd8 ! 0019 ! 000d ! 0007 ! 0003 ENDCHAR STARTCHAR 14-23 ENCODING 11831 *************** *** 28652,28673 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 004c ! 0046 ! 0042 ! ffff ! 0040 ! 0040 ! 0040 ! 7f40 0060 ! 0020 ! 0020 0030 ! 0011 ! ff9b ! 000e ! 0004 ENDCHAR STARTCHAR 14-24 ENCODING 11832 --- 28652,28673 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0050 ! 0068 ! 006c ! 0068 ! 3ffe 0060 ! 0060 ! 00e0 ! 3fe0 0030 ! 0030 ! 0018 ! 0059 ! 7fed ! 0007 ! 0003 ENDCHAR STARTCHAR 14-24 ENCODING 11832 *************** *** 28675,28695 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0044 ! 0042 ! 0040 ! 7fff ! 0040 ! 0040 ! 0040 ! 3f20 ! 0020 ! 0020 ! 3f10 ! 0010 ! 0008 ! 7fc9 ! 0005 0003 ENDCHAR STARTCHAR 14-25 --- 28675,28695 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0050 ! 0068 ! 006c ! 0068 ! 3ffe ! 0060 ! 0160 ! 3fe0 ! 0060 ! 0230 ! 1f30 ! 0019 ! 0099 ! 7fcd ! 0007 0003 ENDCHAR STARTCHAR 14-25 *************** *** 28722,28742 **** BBX 16 16 0 -2 BITMAP 0100 ! 4102 ! 4102 ! 7ffe ! 0100 ! 0380 ! 06c0 ! 0c70 ! 381c ! e7e7 ! 0000 ! 1ff8 ! 1008 ! 1008 ! 1008 ! 1ff8 ENDCHAR STARTCHAR 14-27 ENCODING 11835 --- 28722,28742 ---- BBX 16 16 0 -2 BITMAP 0100 ! 2184 ! 3186 ! 3186 ! 3ffe ! 2364 ! 0630 ! 0c0c ! 1bf7 ! 680a ! 0ffc ! 0c18 ! 0c18 ! 0c18 ! 0ff8 ! 0810 ENDCHAR STARTCHAR 14-27 ENCODING 11835 *************** *** 28744,28765 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0810 ! 1010 ! 21ff ! 4044 ! 0444 ! 09ff ! 1111 ! 3111 ! 50fe ! 1020 ! 1020 ! 103e ! 1042 ! 1042 ! 1082 ! 110c ENDCHAR STARTCHAR 14-28 ENCODING 11836 --- 28744,28765 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0820 ! 0c30 ! 19fe ! 1084 ! 20cc ! 4848 ! 0fff ! 1b23 ! 1b33 ! 39fe ! 5860 ! 187e ! 1866 ! 1866 ! 18ce ! 1184 ENDCHAR STARTCHAR 14-28 ENCODING 11836 *************** *** 28767,28788 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 3fe6 ! 000c 0008 ! 3ff0 ! 2766 ! 2766 ! 3f6c ! 3ff0 ! 2fe2 ! 2f66 ! 276c ! 2f70 ! 2f60 ! 0000 ! 0000 ENDCHAR STARTCHAR 14-29 ENCODING 11837 --- 28767,28788 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0004 ! 0046 ! 7fec 0008 ! 4a58 ! 7fe4 ! 6ac6 ! 6acc ! 6ad8 ! 7bf2 ! 7bc3 ! 6ac6 ! 6acc ! 6ad8 ! 6af0 ! 40c0 ENDCHAR STARTCHAR 14-29 ENCODING 11837 *************** *** 28790,28811 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 0008 ! 1efe ! 02c8 ! 1e70 ! 02fc ! 07fc ! 06f0 ! 06fc ! 3ffc ! 1608 ! 1e7c ! 1638 ! 0e30 ! 04dc ! 0000 ENDCHAR STARTCHAR 14-30 ENCODING 11838 --- 28790,28811 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0124 ! 3fff ! 0324 ! 1f34 ! 037f ! 3fd8 ! 07fe ! 06d8 ! 7ffe ! 46d8 ! 36fe ! 16c4 ! 067e ! 0624 ! 1e18 ! 0ce7 ENDCHAR STARTCHAR 14-30 ENCODING 11838 *************** *** 29181,29202 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 0000 ! 3efe ! 36b2 ! 3efe ! 3eb2 ! 3ebe ! 3e86 ! 3eda ! 3eda ! 3eda ! 3dfa ! 1506 ! 1706 ! 2200 ! 0000 ENDCHAR STARTCHAR 14-47 ENCODING 11855 --- 29181,29202 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 4141 ! 7fff ! 6341 ! 6b49 ! 6b5d ! 6b49 ! 6b49 ! 6b7f ! 6b41 ! 4a5d ! 1c55 ! 1e55 ! 36dd ! 66d5 ! 4783 ! 0301 ENDCHAR STARTCHAR 14-47 ENCODING 11855 *************** *** 29227,29248 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 0002 ! 0a3e ! 0a3e ! 1fbe ! 1bbe ! 1bbe ! 1fbe ! 1bbe ! 1bbe ! 3ff8 ! 0a18 ! 192a ! 10ae ! 20c0 ! 0000 ENDCHAR STARTCHAR 14-49 ENCODING 11857 --- 29227,29248 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0a02 ! 0a7f ! 2ac6 ! 3fd6 ! 2ad6 ! 2ad6 ! 3fd6 ! 2ad6 ! 2ad6 ! 2a94 ! 7ff8 ! 163c ! 1a6d ! 33cd ! 218f ! 4186 ENDCHAR STARTCHAR 14-49 ENCODING 11857 *************** *** 191593,191605 **** 1ac0 7ee1 18ff ! 18a1 18bf ! 18a1 1abf ! 1ea1 713f ! 0221 ENDCHAR STARTCHAR 91-58 ENCODING 31578 --- 191593,191605 ---- 1ac0 7ee1 18ff ! 18b3 18bf ! 18b3 1abf ! 1eb3 713f ! 0211 ENDCHAR STARTCHAR 91-58 ENCODING 31578 *************** *** 191653,191674 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0010 ! 0010 ! 7dff ! 1129 ! 112a ! 1046 ! 1090 ! 7c28 ! 1044 ! 1183 ! 10fe ! 1082 ! 1c82 ! 7082 ! 00fe ! 0082 ENDCHAR STARTCHAR 91-61 ENCODING 31581 --- 191653,191674 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0020 ! 0532 ! 7fff ! 1b53 ! 1ada ! 18ae ! 1b74 ! 7ed8 ! 198c ! 1b07 ! 1dfe ! 198c ! 1b8c ! 1f8c ! 71fc ! 0108 ENDCHAR STARTCHAR 91-61 ENCODING 31581 *************** *** 191768,191789 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 001c ! 0202 ! 7d22 ! 1041 ! 103e ! 1210 ! 1128 ! 7c4d ! 1016 ! 1324 ! 114e ! 1115 ! 1d64 ! 710c ! 0280 ! 047f ENDCHAR STARTCHAR 91-66 ENCODING 31586 --- 191768,191789 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0000 ! 0222 ! 7f14 ! 18be ! 1890 ! 1bea ! 198e ! 7fb4 ! 19ce ! 1997 ! 19a5 ! 19dd ! 1b88 ! 1f80 ! 71ff ! 027e ENDCHAR STARTCHAR 91-66 ENCODING 31586 *************** *** 193263,193284 **** DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0810 ! 2810 ! 2810 ! 3e10 ! 28ff ! 4811 ! 0911 ! 0891 ! 0891 ! 0e91 ! 7821 ! 0821 ! 0822 ! 0842 ! 0842 ! 088c ENDCHAR STARTCHAR 92-37 ENCODING 31813 --- 193263,193284 ---- DWIDTH 16 0 BBX 16 16 0 -2 BITMAP ! 0800 ! 2c02 ! 3dff ! 2c36 ! 3e36 ! 6cb6 ! 4db6 ! 4cf6 ! 0e36 ! 1c66 ! 7c66 ! 2c66 ! 0cc6 ! 0d96 ! 0d0e ! 0e04 ENDCHAR STARTCHAR 92-37 ENCODING 31813 *** hzbanner.1.old Thu Jul 21 11:42:16 1994 --- hzbanner.1 Mon Jul 25 14:31:23 1994 *************** *** 1,4 **** ! .TH HZBANNER 1 "21 July 1994" Local .SH NAME hzbanner \- display Hanzi in large characters .SH SYNOPSYS --- 1,4 ---- ! .TH HZBANNER 1 "25 July 1994" Local .SH NAME hzbanner \- display Hanzi in large characters .SH SYNOPSYS *** hzbanner.c.old Thu Jul 21 11:12:58 1994 --- hzbanner.c Mon Jul 25 15:27:27 1994 *************** *** 1,12 **** ! /* hzbanner (GuoBiao Hanzi banner) Version 0.9 ! by Koichi Yasuoka, July 21, 1994 */ #include extern char *malloc(); ! extern unsigned short *font1[]; FILE *fp; int width=72; ! char *display[8]; main(argc,argv) int argc; --- 1,16 ---- ! /* hzbanner (GuoBiao Hanzi banner) Version 0.91 ! by Koichi Yasuoka, July 25, 1994 */ #include + #include "font1.h" + #define MAXWIDTH FONT1WIDTH + #define MAXHEIGHT FONT1HEIGHT extern char *malloc(); ! extern unsigned char *font1[]; FILE *fp; int width=72; ! char *display[(MAXHEIGHT+1)>>1]; ! char bannerbuf[MAXWIDTH+7][MAXHEIGHT+1]; main(argc,argv) int argc; *************** *** 20,33 **** fprintf(stderr,"Usage: hzbanner [-wn] [file...]\n"); exit(1); } ! if((width=atoi(&(argv[1][2])))<16){ ! fprintf(stderr,"hzbanner: width must be greater than 15\n"); exit(1); } argc--; argv++; } ! for(i=0;i<8;i++){ if((display[i]=malloc(width))==NULL){ fprintf(stderr,"Not enough memory\n"); exit(2); --- 24,37 ---- fprintf(stderr,"Usage: hzbanner [-wn] [file...]\n"); exit(1); } ! if((width=atoi(&(argv[1][2])))>1)-1;i>=0;i--){ if((display[i]=malloc(width))==NULL){ fprintf(stderr,"Not enough memory\n"); exit(2); *************** *** 106,112 **** if(font1[h]==NULL) banner0(' '); else ! banner1(&(font1[h][l<<4])); } } flusht(); --- 110,116 ---- if(font1[h]==NULL) banner0(' '); else ! banner1(&(font1[h][l*FONT1BYTES]),FONT1WIDTH,FONT1HEIGHT,FONT1BYTES); } } flusht(); *************** *** 190,196 **** cleart() { int i,j; ! for(i=0;i<8;i++){ for(j=0;j>1)-1;i>=0;i--){ for(j=0;j=0;k--){ ! if(display[i][k]!=' ') break; } ! for(j=0;j<=k;j++) ! putchar(display[i][j]); putchar('\n'); } } } --- 203,240 ---- flusht() { ! int i,j,k,l; if(displen==0) return; if(dispflag==0){ for(j=0;j>2][j]); putchar('\n'); } else{ ! for(l=((MAXHEIGHT+1)>>1)-1;l>=0;l--){ for(k=displen-1;k>=0;k--){ ! if(display[l][k]!=' ') break; } ! if(k>=0) ! break; ! } ! if(l<0) putchar('\n'); + else{ + j=0; + for(i=0;i<=l;i++){ + for(k=displen-1;k>=0;k--){ + if(display[i][k]!=' ') + break; + } + if(k<0&&j==0) + continue; + for(j=0;j<=k;j++) + putchar(display[i][j]); + putchar('\n'); + } } } } *************** *** 235,282 **** if(c=='\t') c=' '; if(displen>=1) ! l--; ! for(k=1;(j&k)==0;k<<=1) ! l--; ! if(displen+l>width){ flusht(); cleart(); } ! while(i>=k){ ! for(j=0;j<8;j++){ ! if((int)p[j<<1]&i){ ! if((int)p[(j<<1)+1]&i) ! display[j][displen]=';'; else ! display[j][displen]=39; } ! else if((int)p[(j<<1)+1]&i) ! display[j][displen]=','; } displen++; ! i>>=1; } dispflag=1; } --- 254,325 ---- if(c=='\t') c=' '; if(displen>2][displen]=(char)c; displen++; return; } flusht(); cleart(); ! display[MAXHEIGHT>>2][displen++]=(char)c; } ! banner1(p,w,h,b) ! unsigned char p[]; ! int w,h,b; { ! int i,j,x,y; ! for(x=0;x>2)&0xfffe); ! for(i=0;i0;j>>=1) ! bannerbuf[x++][y]=(((int)p[i]&j)!=0); ! if(x>=w){ ! x=0; ! y++; ! } ! } ! for(x=w-1;x>=0;x--){ ! for(y=0;y=width){ flusht(); cleart(); } ! while(x<=i){ ! for(y=0;y>1][displen]=';'; else ! display[y>>1][displen]=39; } ! else if(bannerbuf[x][y+1]) ! display[y>>1][displen]=','; } displen++; ! x++; } dispflag=1; } From cyl Wed Jul 27 11:11:41 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA14501; Wed, 27 Jul 94 11:11:41 CDT Date: Wed, 27 Jul 1994 11:11:40 -0500 (CDT) From: Nelson CHIN Subject: HBF draft now in html format. To: soft-authors@ifcss.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O Thanks to Ross, the HBF draft is now in html format: http://ifcss.org:8001/www/pub/software/info/HBFdraft/index.html if you only have ftp access, then get ifcss.org:/software/info/HBFdraft.tar.gz or the text output of the html ifcss.org:/software/info/HBFdraft/HBF.txt sample single/triple byte HBF file is not incorporated yet at the appendix. Please check it out and comment. Nelson From simpson@math.psu.edu Thu Jul 28 15:01:07 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA12032; Thu, 28 Jul 94 15:01:07 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id PAA07783; Thu, 28 Jul 1994 15:58:35 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Thu, 28 Jul 1994 15:58:33 -0400 Date: Thu, 28 Jul 1994 15:58:33 -0400 Message-Id: <199407281958.PAA27104@boole.math.psu.edu> To: chinesenet@uclink.berkeley.edu Cc: soft-authors@ifcss.org, ccnet-l@uga.cc.uga.edu Subject: HZ+ and chinese.* Reply-To: simpson@math.psu.edu Status: O Hi Ning and others, BACKGROUND As you know, GB and Big5 are the most popular Chinese coding standards worldwide. GB is preferred by mainlanders and others who use simplified characters, while Big5 is preferred by Taiwanese and others who use traditional characters. A problem arises because the Internet is not 8-bit clean. HZ partially solves this problem by providing a convenient 7-bit representation of mixed ASCII and GB. For this reason, HZ has been very popular and successful, for example in the alt.chinese.text newsgroup, which is why HZ was also adopted as the standard for the chinese.* newsgroup hierarchy. WHAT IS HZ+ ? HZ+ is a simple extension of HZ which I devised in April 1994. The purpose of HZ+ is to provide a convenient 7-bit representation of mixed ASCII, GB, and Big5. Thus HZ+ is compatible with HZ but in addition accommodates Big5. In this way, the benefits of HZ become available to Taiwanese and other Big5 users. As you know, I have been trying to promote HZ+ for use in the chinese.* newsgroup hierarchy and elsewhere on the Internet. WHAT IS THE CURRENT STATUS OF HZ+ ? There are two principal Internet mailing lists for technical matters related to Chinese software: ccnet-l and soft-authors. I'm sorry to say that, despite months of effort, I have been unable to obtain a consensus for HZ+ in either of these lists. Many people like HZ+, but other people have been pushing alternative plans. Some of these are "high road" plans based on official, internationally approved, multilingual standards such as ISO-2022 and Unicode. My opinion is that ISO-2022 and Unicode may be useful in the long term, but right now we clearly need a "low road" solution based on popular Chinese standards such as HZ and Big5. That is my rationale for HZ+. WHAT'S NEXT ? Despite the lack of consensus in ccnet-l and soft-authors, I still hope that HZ+ may be useful in forums such as chinese.*. My advice to the chinese.* organizers would be to encourage postings in HZ, HZ+, and 7-bit versions of ISO-2022 and Unicode. In this way we can find out which standard is most suitable for the purpose. I would be glad to help in any way I can. Right now, the best thing that can be done to promote HZ+ is to use it on the Internet. For instance, we can use it to post messages in chinese.test. My HZ+ software is very simple and is available for anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/hzp. Sincerely, -- 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 Home phone +1 814 238-2274 E-mail simpson@math.psu.edu FAX +1 814 865-3735 World Wide Web http://www.math.psu.edu/simpson/ From cyl Thu Jul 28 20:35:14 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA24631; Thu, 28 Jul 94 20:35:14 CDT Date: Thu, 28 Jul 1994 20:35:12 -0500 (CDT) From: Nelson CHIN Sender: Nelson CHIN Reply-To: Nelson CHIN Subject: Re: HZ+ and chinese.* To: chinesenet@uclink.berkeley.edu Cc: soft-authors@ifcss.org, ftp-admin@ifcss.org In-Reply-To: <199407281958.PAA27104@boole.math.psu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: O On Thu, 28 Jul 1994, Stephen G Simpson wrote: > > WHAT'S NEXT ? > > Despite the lack of consensus in ccnet-l and soft-authors, I still > hope that HZ+ may be useful in forums such as chinese.*. My advice to > the chinese.* organizers would be to encourage postings in HZ, HZ+, > and 7-bit versions of ISO-2022 and Unicode. In this way we can find > out which standard is most suitable for the purpose. I would be glad > to help in any way I can. The way i've been posting BIG5 to chinese.* is through the b2h mail gateway, such as chinese.comp.software%usenet.csie.nctu.edu.tw@b2h.csie.nctu.edu.tw so as to keep the code uniform in the chinese.* newsgroups. If we do allow any 7-bit encoding to enter chinese.* newsgroups, this implies that mirroring option is dropped, because (1) support big-5 via 7-bit protocol (2) it's hard to mirror a heterogenous coded newsgroup. also, you did not mention other HZ extensions, are those excluded from the general heirachy? if multiple codings are allowed to co-exist, posters should note the type of code they're using in the subject line if it's not regular HZ. on another, matter i'll be away to Asuncion Paraguay S.America Aug 3-17 for Christian community service work with the local Indians sponsored in part by my chinese church, and also tomorrow (Friday) i'll be at UNDP, NYC for some global environment presentations/discussions. If there's anything that requires my specific attention, please wait upon my return. (Xiaofei, can you maintain soft-authors while i'm away, and someone take care of the questions to ftp-admin next month). It's getting hot here.... oh ,well.. later, Nelson From xiaofei Thu Jul 28 21:35:23 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA27126; Thu, 28 Jul 94 21:35:23 CDT Date: Thu, 28 Jul 94 21:35:23 CDT From: xiaofei (XiaoFei Wang) Message-Id: <9407290235.AA27126@ifcss.org> To: xiaofei Subject: Re: HZ+ and chinese.* Cc: ftp-admin, soft-authors Status: O :(Xiaofei, can you maintain soft-authors while i'm away, :and someone take care of the questions to ftp-admin next month). : Nelson OK, I can handle both: Please mail sign on/off message to soft-authors to me until Nelson's return. And I will start to answer questions to ftp-admin tomorrow. From simpson@math.psu.edu Fri Jul 29 13:45:59 1994 Return-Path: Received: from leibniz.math.psu.edu by ifcss.org (4.1/IFCSS-Mailer) id AA00187; Fri, 29 Jul 94 13:45:59 CDT Received: from boole.math.psu.edu (simpson@boole.math.psu.edu [146.186.131.137]) by leibniz.math.psu.edu (8.6.4/8.5) with ESMTP id OAA15622; Fri, 29 Jul 1994 14:43:30 -0400 From: Stephen G Simpson Received: from localhost by boole.math.psu.edu id ; Fri, 29 Jul 1994 14:43:28 -0400 Date: Fri, 29 Jul 1994 14:43:28 -0400 Message-Id: <199407291843.OAA29272@boole.math.psu.edu> To: Nelson CHIN Cc: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org, chinesenet@uclink.berkeley.edu Subject: Re: HZ+ and chinese.* In-Reply-To: References: <199407281958.PAA27104@boole.math.psu.edu> Reply-To: simpson@math.psu.edu Status: O Nelson CHIN writes: > The way i've been posting BIG5 to chinese.* is through the b2h > mail gateway, such as > chinese.comp.software%usenet.csie.nctu.edu.tw@b2h.csie.nctu.edu.tw > so as to keep the code uniform in the chinese.* newsgroups. What kind of mirror is this, and how does it work? Does it translate Big5 to HZ? > If we do allow any 7-bit encoding to enter chinese.* newsgroups, this > implies that mirroring option is dropped, because > (1) support big-5 via 7-bit protocol > (2) it's hard to mirror a heterogenous coded newsgroup. I don't understand this remark completely. HZ+ is in a sense heterogeneous, because it supports both GB and Big5. But if somebody wants to mirror an HZ+ newsgroup, I don't see why this should present any difficulty. My "How To" document explains how to translate HZ+ into pure GB or pure Big5, if that is desired. > also, you did not mention other HZ extensions, are those excluded from > the general heirachy? if multiple codings are allowed to co-exist, > posters should note the type of code they're using in the subject line > if it's not regular HZ. So far as I know, HZ is the only coding system currently allowed in the general chinese.* hierarchy. But other coding systems are allowed in chinese.test. If somebody wants to promote HZ+, one way to do so would be to use it to post in chinese.test. My HZ+ software is available for anonymous FTP at ftp.math.psu.edu, /pub/simpson/chinese/hzp. -- Steve From deng@bunny.rhic.bnl.gov Fri Jul 29 15:35:12 1994 Return-Path: Received: from bunny.rhic.bnl.gov.zoo by ifcss.org (4.1/IFCSS-Mailer) id AA05101; Fri, 29 Jul 94 15:35:12 CDT Received: by bunny.rhic.bnl.gov.zoo (4.1/SMI-4.1) id AA02324; Fri, 29 Jul 94 16:34:53 EDT Message-Id: <9407292034.AA02324@bunny.rhic.bnl.gov.zoo> X-Phone: (516) 282-2197 (o), 266-6241 (h) X-Fax: (516) 282-2588 To: simpson@math.psu.edu Cc: Nelson CHIN , ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org, chinesenet@uclink.berkeley.edu Subject: Re: HZ+ and chinese.* In-Reply-To: Your message of "Fri, 29 Jul 94 14:43:28 EDT." <199407291843.OAA29272@boole.math.psu.edu> Date: Fri, 29 Jul 94 16:34:52 -0400 From: D-P Deng Status: O >>>>> On Fri, 29 Jul 94 14:43:28 EDT, Stephen G Simpson said: Stephen> So far as I know, HZ is the only coding system currently allowed Stephen> in the general chinese.* hierarchy. But other coding systems are Stephen> allowed in chinese.test. If somebody wants to promote HZ+, one Stephen> way to do so would be to use it to post in chinese.test. My HZ+ Stephen> software is available for anonymous FTP at ftp.math.psu.edu, Stephen> /pub/simpson/chinese/hzp. My understanding is this. In reality, no one is enforcing hz, you can post ANYTHING in the general chinese.* hierarchy. HZ coding is just an eazy way to kick off the chinese.* hierarchy. For all you coding designers, you can "fight" (post your instructions and articles) it out in chinese.* ;-) Dong-Ping