home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / internat / 982 < prev    next >
Encoding:
Text File  |  1993-01-01  |  8.6 KB  |  211 lines
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!smurf.sub.org!incom!kostis!blues!kosta
  2. From: kosta@blues.kk.sub.org (Kosta Kostis)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
  6. Message-ID: <DwqPwB3w165w@blues.kk.sub.org>
  7. Date: Fri, 01 Jan 93 20:34:36 MET
  8. References: <1hu9v5INNbp1@rodan.UU.NET>
  9. Organization: The Blues Family
  10. Lines: 199
  11.  
  12. avg@rodan.UU.NET (Vadim Antonov) writes:
  13.  
  14. > 1) "mechanistic" conversion between upper and lower case
  15. >    is impossible (as well as case-insensitive comparisons)
  16. > 
  17. >    Example:     Latin  T -> t
  18. >               Cyrillic T -> m
  19. >               Greek T -> ?
  20.  
  21. What do you consider a "mechanistic" case conversion?
  22.  
  23. UniCode includes all the characters defined in ISO 8859-x.
  24. Is case conversion a real problem with these?
  25. We need more "clever" conversion routines.
  26.  
  27. Whenever you want to convert a characters case or want to sort things,
  28. the language used is one of the parameters, not only the character code.
  29.  
  30. >    This property alone renders Unicode useless for any business
  31. >    applications.
  32.  
  33. You really had a look at UniCode, hadn't you?  :-)
  34.  
  35. UniCode is limited because everything is squeezed into 16-bit, but
  36. for latin languages (and the like) it's just fine.
  37.  
  38. > 2) there is no trivial way to sort anything.
  39. >    An elementary sort program will require access to enormous
  40. >    tables for all possible languages.
  41. > 
  42. >    English: A B C D E ... T ...
  43. >    Russian: A .. B ... E ... C T ...
  44.  
  45. This is a problem regardless of the character set being used.
  46. Why do you blame UniCode for that?
  47.  
  48. > 3) there is no reasonable way to do hyphenation.
  49. >    Since there is no way to tell language from the text there
  50. >    is no way to do any reasonable attempts to hyphenate.
  51. >    [OX - which language this word is from]?
  52. > 
  53. >    Good-bye wordprocessors and formatters?
  54.  
  55. No. It's a big "hello" for *good* wordprocessors and formatters that
  56. "know" about the language the words are written in and they *need* to
  57. know that to perform correct actions. This is again regardless of the
  58. character set being used. No reason to blame UniCode *here*.
  59.  
  60. > 4) "the similar gliphs" in Unicode are often SLIGHTLY different
  61. >    typographical gliphs -- everybody who ever dealt with international
  62. >    publishing knows that fonts are designed as a WHOLE and every
  63. >    letter is designed with all others in mind -- i.e. X in Cyrillic
  64. >    is NOT the same X as Latin even if the fonts are variations of
  65. >    the same style. I'd wish you to see how ugly the Russian
  66. >    texts prited on American desktop publishing systems with
  67. >    "few characters added" are.
  68.  
  69. The Cyrillic "X" is *not* the same as the Latin 1 "X" in UniCode,
  70. as you might know. Have you ever tried this with an "american DTP system"
  71. that uses UniCode?   :-)  I don't think so...
  72.  
  73. >    In reality it means that Unicode is not a solution for
  74. >    typesetting.
  75.  
  76. Come on. What did you expect? A universal character set is not the
  77. "solution", it's just intended to help you develop it.
  78.  
  79. Anyway I doubt there will ever *a* solution for this field.
  80. Even with UniCode I guess there will be many solutions covering
  81. just facets of the whole "problem".
  82.  
  83. > Having unique glyphs works ONLY WITHIN a group of languages
  84. > which are based on variations of a single alphabet with
  85. > non-conflicting alphabetical ordering and sets of
  86. > vowels. You can do that for European languages.
  87.  
  88. You can't. Maybe you should learn more about European languages. ;-)
  89.  
  90. > An attempt to do it for different groups (like Cyrillic and Latin)
  91. > is disastrous at best -- we already tried is and finally came to
  92. > the encodings with two absolutely separate alphabets.
  93.  
  94. That's what's done in ISO 8859-5 and what UniCode does. RTFM.  :-)
  95.  
  96. > I think that there is no many such groups, though, and it is possible
  97. > to identify several "meta-alpahbets". The meta-alphabets have no
  98. > defined rules for cross-sorting (unlike latters WITHIN one
  99. > meta-alphabet; you CAN sort English and German words together
  100. > and it still will make sense; 
  101.  
  102. Why do you think it would make sense?
  103.  
  104. It won't make sense. Lexical sorting makes only sense, if at all, in
  105. *one* single language. You will have to sort data with the attribut
  106. "language" if you want to do it correctly in any case, either implied
  107. or added explicitly. A sorting program made for Russian text in e. g.
  108. ISO 8859-5 may do the job well for exactly that, it will create trash
  109. when run over German text coded in ISO 8859-1. A "general" sorting
  110. program would be so complex that it's *almost* impossible to do.
  111. It will at least be very much memory and CPU consuming at it will
  112. take years (many years) to develop it. I'd love to be wrong here.
  113.  
  114. >                               sorting Russian and English together
  115. > is at best useless). It increases the number of codes but not
  116. > as drastically as codifying languages; there are hundreds of
  117. > languages based on a dozen of meta-alphabets.
  118.  
  119. Why should you want to sort data with mixed Russian and e. g. English
  120. words anyway? If you do so using plain character sets instead of clever
  121. algorithms, you must fail hopelessly.
  122.  
  123. > >The fact that all character sets do not occur in their local lexical order
  124. > >means that a particular character can not be identified as to language by
  125. > >its ordinal value.  This is a small penalty to pay for the vast reduction
  126. > >in storage requirements between a 32-bit and a 16-bit character set that
  127. > >contains all required glyphs.
  128.  
  129. (sorry, Vadim, I know you didn't write the above)
  130.  
  131. Who defines "required"? This is a classical "don't care about the
  132. users culture/needs" approach that was so harmfull in the past.
  133.  
  134. > Not true. First of all nothing forces to use 32-bit representation
  135. > where only 10 bits are necessary.
  136.  
  137. 10 bits? You want to keep Asian languages out of the game, too?  :-)
  138.  
  139. Transfering 10-bit will cost the same as 16-bit if you don't do some
  140. tricky encoding which I don't think I want to have, do you?
  141.  
  142. This assumes you organize/store character data in multiple 8-bit
  143. octets which should be true for the vast majority of computers today
  144. and in the future.
  145.  
  146. > So, as you see the Unicode is more a problem than a solution.
  147.  
  148. No, I think it's more like one step aside and one towards a solution.
  149.  
  150. > The fundamental idea is simply wrong -- it is inadequate for
  151. > anything except for Latin-based languages. No wonder we're
  152. > hearing that Unicode is US-centric.
  153.  
  154. I agree that UniCode is not very good for Asian languages, but
  155. for European languages (and some more) it's really OK. Should
  156. we ever decide to use the full 32-bits ISO 10646 intended to
  157. allocate for character codes, we should be able to cover almost
  158. all languages (to some extend).
  159.  
  160. Digital systems and numbering systems in general are limited.
  161. You can get close to the "original", but you will never be able
  162. to do more than an approximation, but that's another story.  ;-)
  163.  
  164. > Unfortunately Unicode looks like a cool solution for people who
  165. > never did any real localization work and i fear that this
  166. > particular mistake will be promoted as standard presenting
  167. > us a new round of headache. It does not remove necessity to
  168. > carry off-text information (like "X-Language: english") and
  169. > it makes it not better than existing ISO 8-bit encodings
  170. > (if i know the language i already know its alphabet --
  171.  
  172. No, you don't. Look at the existing ISO 8-bit encodings, namely
  173. ISO 8859-x and you can see that many languages can be encoded in
  174. several character sets. You will always have to include a language
  175. tag if the language is not implied.
  176.  
  177. > all extra bits are simply wasted; and programs handling Unicode
  178. > text have to know the laguage for reasons stated before).
  179.  
  180. Extra bits aren't wasted. 10-bit or 16-bit make no real difference. 
  181.  
  182. > UNICODE IS A *BIG* MISTAKE.
  183.  
  184. This may be your opinion, but I don't agree. It's still a better
  185. "mistake" than plain US ASCII and it's better than 8-bit encodings
  186. and/or character set switching.  ;-)
  187.  
  188. > (Don't get me wrong -- i'm for the universal encoding; it's
  189. > just that particular idea of unique glyphs that i strongly
  190. > oppose).
  191.  
  192. I agree. Unique glyphs are important, and this is not done for
  193. Japanese, Chinese and Korean(?). Well, at least not for those... :-)
  194.  
  195. The other languages you stated, like Russian, Greek and English
  196. seem to be served well by UniCode, I think.
  197.  
  198. As much as I can see no universal character set will ever *solve*
  199. the problems arising from sorting, case conversion, hyphenation
  200. and many more, thus we shouldn't expect that.
  201.  
  202. > --vadim
  203.  
  204.     Kosta
  205.  
  206.  
  207. -- 
  208.   Kosta Kostis, Talstrasse 25, D-6074 Roedermark 3, Germany
  209.   kosta@blues.kk.sub.org                                        (home)
  210.   sw authors: please support ISO 8859-x!      Σ÷ⁿ─╓▄▀ = aeoeueAEOEUEss
  211.