home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / internat / 1276 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  1.8 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!cs.titech!titccy.cc.titech!necom830!mohta
  2. From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Radicals Instead of Characters
  5. Message-ID: <2791@titccy.cc.titech.ac.jp>
  6. Date: 22 Jan 93 09:44:54 GMT
  7. References: <1j8kroINNf59@flop.ENGR.ORST.EDU> <ISHIKAWA.93Jan18203811@ds5200.personal-media.co.jp> <1j9sfpINN46t@life.ai.mit.edu> <1jfgq1INNqmn@flop.ENGR.ORST.EDU>
  8. Sender: news@titccy.cc.titech.ac.jp
  9. Organization: Tokyo Institute of Technology
  10. Lines: 36
  11.  
  12. In article <1jfgq1INNqmn@flop.ENGR.ORST.EDU>
  13.     crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
  14.  
  15. >The question I was asking was "can you _identify_ a han/kanji character
  16. >based on a sequence of radicals"
  17.  
  18. No, you can't. Radicals are for indexing only. The rest of the character
  19. has its own complex shape.
  20.  
  21. >and "would it be reasonable to encode
  22. >han/kanji on that basis".
  23.  
  24. Such encoding is too lengthy.
  25.  
  26. >Agreed.  However, there is no natural size for tables.  Table sized of
  27. >4000 are much cheaper than table sizes of 64000.
  28.  
  29. If you use radical based encoding, it makes everything complex.
  30.  
  31. Moreover, you will have to have sixteen 4000 entry tables which is as
  32. large as a single 64000 entry table.
  33.  
  34. >But, can sixteen bits represent _all_ historical Han characters _and_
  35. >the historical texts of all other languages?  My guess is 16 bits can
  36. >_if_ Han characters are coded as radicals,
  37.  
  38. Maybe nor may not be. Many complex Han characters are just unique.
  39.  
  40. >If the level 1 Han characters were also coded as radicals where
  41. >possible, you'd have a coding system like what I was proposing.  Of
  42. >course, the charactes might be several radicals long.
  43.  
  44. BTW, from the view point of programmers, combining characters are
  45. just unusable.
  46.  
  47.                         Masataka Ohta
  48.