home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / internat / 1135 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  4.8 KB
  1. Path: sparky!uunet!ogicse!mintaka.lcs.mit.edu!ai-lab!wheat-chex!glenn
  2. From: glenn@wheat-chex.ai.mit.edu (Glenn A. Adams)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Dumb Americans (was INTERNATIONALIZATION: JAPAN, FAR EAST)
  5. Keywords: Unicode ISO10646 CharacterEncoding
  6. Message-ID: <1ipo2kINN6g2@life.ai.mit.edu>
  7. Date: 10 Jan 93 17:57:40 GMT
  8. Article-I.D.: life.1ipo2kINN6g2
  9. References: <1993Jan9.024546.26934@fcom.cc.utah.edu> <1in2c8INNmbj@life.ai.mit.edu> <1993Jan10.000115.28150@fcom.cc.utah.edu>
  10. Organization: MIT Artificial Intelligence Laboratory
  11. Lines: 87
  12. NNTP-Posting-Host: wheat-chex.ai.mit.edu
  13.  
  14. In article <1993Jan10.000115.28150@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
  15. >I agree; however, given my objections to UTF, the only potential use for
  16. >it in my book would be interchange of data between systems, and in
  17. >particular, with Plan 9 systems, which are already committed to UTF for
  18. >storage, interchange, and processing.
  19.  
  20. The original UTF (UTF1), as described in DIS10646-1.2:1992, was defined
  21. for one purpose only:  to facilitate interchange of 10646 data over
  22. 8-bit interchange channels sensitive to C0/C1/SPACE/DEL octet values
  23. (i.e., 8-bit ISO2022 interchange channels).  There was no intent in
  24. using this for direct processing, nor for file system storage (though
  25. these weren't ruled out).
  26.  
  27. The FSS-UTF (UTF2), developed by Ken Thompson, and used in Plan9, had
  28. a different set of goals which were established by their usage requirements.
  29. I would not claim that UTF2 is inappropriate given the goals articulated
  30. by the Plan9 designers; however, I do not believe one should take
  31. their goals to be those of the Unicode/10646 community at large.  Most
  32. Unicode/10646 implementors that I'm aware of, tend to use 10646 UCS2
  33. (Unicode) fixed width 16-bit encodings only, for both processing and
  34. interchange.
  35.  
  36. >In my opinion, UTF and other species of what I have been calling "Runic
  37. >encoding" are inappropriate for storage of non per-language attributable
  38. >data.
  39.  
  40. I think you may be misusing the term as Ken Thompson used it (I believe)
  41. to refer to fixed width 16-bit 10646 UCS2 (Unicode) encodings, and not to
  42. the variable width UTF encodings.  The term "multibyte" encoding as
  43. currently used in the Posix, X/Open, and Unix communities tends to be
  44. used for what is equivalent to UTF variable length multibyte encodings.
  45.  
  46. >This [language attribution] *must* be in-band for multilingual Unicode
  47. >documents if we are to overcome the (I believe reasonable) objection to
  48. >the lack of information for display localization.
  49.  
  50. No, this is incorrect.  Language attribution *is not* necessary for
  51. the legible display of any multilingual Unicode data.  That is, unless
  52. you consider that font attribution is necessary for display.  Neither
  53. Ohta-san's claims nor Vadim's claims have shown that language attributes
  54. are necessary to perform legible display.  If you (or anyone else) can
  55. demonstrably show this to be the case, then I welcome you to do it.
  56. Otherwise, you can take my word (having implemented a Unicode rendering
  57. engine) that language attributes are not necessary.
  58.  
  59. I agree that language attribution is desirable for typographically
  60. correct display; however, so are font and style attributes.
  61.  
  62. >The destruction of information, like record boundries or an aritmmetic
  63. >relationship between the character count in a document and the number of
  64. >bytes in a file, is unavoidable in a Unicode implementation (10646 can
  65. >escape this by implementing Vadim or Ohta's "super character set" elsewhere
  66. >in the vastly larger space provided by the 32 bit space).
  67.  
  68. No, this is incorrect:
  69.  
  70.   byte_count = unicode_char_count * sizeof (unsigned short)
  71.  
  72. Your claim is only true in the context of UTF(s), not Unicode (or 10646)
  73. in general. 
  74.  
  75. >until such time as the high 16 bits of 10646 come into use
  76.  
  77. Actually, there are only 15 usable high bits in 10646, bit 31 is
  78. reserved and MBZ.  I wouldn't look for any characters being defined
  79. outside the BMP (lower 16-bits) for 5 years or more.  Even then,
  80. I don't see any need for it, nor do I see any reason that, should
  81. additional non-BMP characters be defined, any major vendors will
  82. pay any attention to them.
  83.  
  84. Why should someone support 10646 UCS4 when UCS2 gives you everything
  85. that is needed.  [I am assuming here that ISO JTC1/SC2/WG2 will not
  86. sanction encodings outside of UCS2 simply for the purpose of providing
  87. implicit language attributions.  If this were proposed, I suspect WG2
  88. would claim that language attributes are beyond the scope of character
  89. encoding, and, instead, require it be addressed in another standards
  90. context.]
  91.  
  92. >To my mind, the way UTF is formulated seems like a buy-off of the 7-bit
  93. >ASCII world, with little benefit to non (or only partial) 7-bit ASCII
  94. >users.
  95.  
  96. UTF2 buys significant software backward compatibility with many 8-bit
  97. clean for ASCII only applications.  I believe that was its design goal,
  98. so it can't be faulted on that basis.
  99.  
  100. Glenn Adams
  101.