home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1088 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  4.0 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: Language tagging
  5. Message-ID: <2643@titccy.cc.titech.ac.jp>
  6. Date: 7 Jan 93 13:09:38 GMT
  7. References: <1993Jan3.203017.232@enea.se> <2609@titccy.cc.titech.ac.jp> <1iav6tINNee2@life.ai.mit.edu> <1iddeeINN58g@rodan.UU.NET> <TT.93Jan7085019@tarzan.jyu.fi>
  8. Sender: news@titccy.cc.titech.ac.jp
  9. Organization: Tokyo Institute of Technology
  10. Lines: 96
  11.  
  12. In article <TT.93Jan7085019@tarzan.jyu.fi>
  13.     tt@tarzan.jyu.fi (Tapani Tarvainen) writes:
  14.  
  15. >>Now, i think everybody agrees that the "ultimate encoding" is
  16. >>the one which provides the complete information about which
  17. >>language is used -- it sovles all the problems.
  18. >
  19. >While such an encoding might be called "ultimate",
  20.  
  21. Agreed. As the proposal is much more rational than 10646 and can not
  22. be compatible with 10646, let's throw away 10646/Unicode and make the
  23. UCS (Ultimate coded Character Set).
  24.  
  25. >it wouldn't solve
  26. >all problems.  In particular, the encoding mustn't force one to
  27. >provide information that's irrelevant or not available.
  28.  
  29. There should be one language code: wild card.
  30.  
  31. If the language distiction information is not available, we should
  32. assign wild card code to the character, which will match with
  33. characters of any language.
  34.  
  35. >>2) there is an *algorithm* for converting from upper case to lower case
  36. >>   and vice versa.
  37. >
  38. >>   This property is extremely useful
  39. >
  40. >Agreed.  It is also very difficult to do completely for all languages
  41. >without knowing the language.  E.g., in some languages several lower
  42. >case characters may map to same upper case character.  Perhaps it
  43. >would be sufficient to have a case-insensitive comparison algorithm?
  44.  
  45. Agreed.
  46.  
  47. >A pure locale-system clearly won't do in multilingual environments.
  48. >Nonetheless some things are, IMHO, best handled with locales.
  49.  
  50. Agreed.
  51.  
  52. >However, there's another issue with sorting where your proposal is
  53. >disastrous:  A single list of names may need to be sorted differently
  54. >on different occasions depending on the target language.  If Spanish
  55. >ll and ch are considered individual characters, and German and Finnish
  56. >a-umlaut as distinct characters, this means that a Finnish reader must
  57. >know the language a name originated in in order to find it.
  58.  
  59. Are 'll' and 'ch' considered individual characers having distinct code
  60. points? Or are 'l', 'l', 'c' and 'h'?
  61.  
  62. I think latter better.
  63.  
  64. >It is
  65. >impossible to explain to a layman that M"oller and M"oller are
  66. >different names and in different place in the directory because one is
  67. >German and the other Swedish.
  68.  
  69. In this case, of course, language distinction should be the last key
  70. used for sorting,
  71. shouldn't it?
  72.  
  73. >Even worse, the problem isn't limited to sorting:  E.g., assume you
  74. >want to search a database for the works of one Mr. M"oller without
  75. >knowing where he comes from.  Or when entering a reference you have
  76. >on paper to a database: how do you know which "o to type?
  77.  
  78. I think the problem can be solved by introducing new notation of
  79. regular expressions.
  80.  
  81. For example, let '[[A]]' represent all latin alphabet 'A's regardless of its
  82. language, and let '[[[a]]]' represent all variants of latin alphabet 'A's
  83. such as "A with ring above".
  84.  
  85. Then, if you want to search Mr. M"oller of any nationality, use the
  86. following pattern
  87.  
  88.         [[M]][["o]][[l]][[l]][[e]][[r]]
  89.  
  90. or just use characters of wild card nationality.
  91.  
  92. >>5) typographical-quality fonts often differentiate between
  93. >>   "similar" glyhps reproducible on lower-resolution devices.
  94.  
  95. It should be stressed that corresponding characters in China and Japan
  96. are differnt even on high resolution CRTs.
  97.  
  98. >>The idea is to leave ALL language specifics at the point of input
  99. >>where the language is supposedly known.
  100.  
  101. How many, do you think, nationality distinction is necessary for
  102. a given single character?
  103.  
  104. It seems to me that, for Han characters, we need 5 or so and it could
  105. be represented with 3 bits.
  106.  
  107.                         Masataka Ohta
  108.