home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / internat / 1285 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.6 KB
  1. Path: sparky!uunet!sequent!gaia.ucs.orst.edu!flop.ENGR.ORST.EDU!jade.CS.ORST.EDU!crowl
  2. From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Radicals Instead of Characters
  5. Date: 22 Jan 1993 19:52:28 GMT
  6. Organization: Computer Science Department, Oregon State University
  7. Lines: 56
  8. Message-ID: <1jpj9sINNlie@flop.ENGR.ORST.EDU>
  9. References: <1j9sfpINN46t@life.ai.mit.edu> <1jfgq1INNqmn@flop.ENGR.ORST.EDU> <2791@titccy.cc.titech.ac.jp>
  10. NNTP-Posting-Host: jade.cs.orst.edu
  11.  
  12. In article <2791@titccy.cc.titech.ac.jp>
  13. mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
  14. >In article <1jfgq1INNqmn@flop.ENGR.ORST.EDU>
  15. >    crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
  16. >
  17. >>The question I was asking was "can you _identify_ a han/kanji character
  18. >>based on a sequence of radicals"
  19. >
  20. >No, you can't. Radicals are for indexing only. The rest of the character
  21. >has its own complex shape.
  22.  
  23. If you can use radicals for indexing, then you can use them to identify
  24. characters.  The process of identifying a character need not be able
  25. to, by itself, generate an acceptable image.
  26.  
  27. >>and "would it be reasonable to encode
  28. >>han/kanji on that basis".
  29. >
  30. >Such encoding is too lengthy.
  31.  
  32. An encoding every variant of every character ever written is not?  At
  33. 214 radicals, we can represent a radical in eight bits, and a character
  34. in 8*(average number of radicals per character).  Your non-unified
  35. approach would require roughly eighteen bits per character.
  36.  
  37. >>Agreed.  However, there is no natural size for tables.  Table sized of
  38. >>4000 are much cheaper than table sizes of 64000.
  39. >
  40. >If you use radical based encoding, it makes everything complex.
  41.  
  42. Could you please elaborate?  Your argument leaves me unconvinced.
  43.  
  44. >Moreover, you will have to have sixteen 4000 entry tables which is as
  45. >large as a single 64000 entry table.
  46.  
  47. No, I don't have to have sixteen 4000 entry tables.  I only need one.
  48.  
  49. >>But, can sixteen bits represent _all_ historical Han characters _and_
  50. >>the historical texts of all other languages?  My guess is 16 bits can
  51. >>_if_ Han characters are coded as radicals,
  52. >
  53. >Maybe nor may not be. Many complex Han characters are just unique.
  54.  
  55. Unique in what sense?  Examples?
  56.  
  57. >BTW, from the view point of programmers, combining characters are
  58. >just unusable.
  59.  
  60. I am a programmer.  It is from a programmer's view that I made my
  61. proposal.  What I am proposing is not unusable.  In many ways it is
  62. more usable that straight character coding.
  63.  
  64. -- 
  65.   Lawrence Crowl        503-737-2554    Computer Science Department
  66.                crowl@cs.orst.edu    Oregon State University
  67.           ...!hplabs!hp-pcd!orstcs!crowl    Corvallis, Oregon,  97331-3202
  68.