home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / bsd / 10681 < prev    next >
Encoding:
Text File  |  1992-12-28  |  4.4 KB  |  87 lines

  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: INTERNATIONALIZATION: JAPAN, FAR EAST
  5. Message-ID: <1992Dec28.065540.24637@fcom.cc.utah.edu>
  6. Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: University of Utah Computer Center
  9. References: <1992Dec18.212323.26882@netcom.com> <1992Dec19.083137.4400@fcom.cc.utah.edu> <2564@titccy.cc.titech.ac.jp> <1992Dec27.223146.5959@rs6000.cmp.ilstu.edu>
  10. Date: Mon, 28 Dec 92 06:55:40 GMT
  11. Lines: 74
  12.  
  13. In article <1992Dec27.223146.5959@rs6000.cmp.ilstu.edu>, jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes:
  14. |> In article <2564@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
  15. |> >
  16. |> >Do you know that Japan vote AGAINST ISO10646/Unicode, because it's not
  17. |> >good for Japanese?
  18. |> >
  19. |> >>So even if the Unicode standard ignores backward compatability
  20. |> >>with Japanese standards (and specific American and European standards),
  21. |> >>it better supports true internationalization.
  22. |> >
  23. |> >The reason of disapproval is not backward compatibility.
  24. |> >
  25. |> >The reason is that, with Unicode, we can't achieve internationalization.
  26. |> >
  27. |> >Unicode can not cover both Japanese and Chinese at the same time, because
  28. |> >the same code points are shared between similar characters in Japan
  29. |> >and in China.
  30. |> >
  31. |> >Of course, it is possible to LOCALIZE Unicode so that it produces
  32. |> >Japanese characters only or Chinese characters only. But don't we
  33. |> >need internationalization?
  34. |> >
  35. |> 
  36. |> I have been following this discussion for some time, despite the
  37. |> (IMHO) obnoxious header :-).  I have been surprised that up until
  38. |> now the 32-bit proposed standard (I no longer recall the OSI number)
  39. |> has not been mentioned.  I personally would prefer this, for the
  40. |> reasons stated above (japanese/chines collisions in Unicode).  Furthermore,
  41. |> for research involving ancient egyption texts or other "obscure" languages,
  42. |> 16 bits even with some expandability would probably not be sufficient.
  43.  
  44. I would also like to see this (although I believe the 32 bit standard in
  45. question is Unicode-32).
  46.  
  47. I wonder at the transcribability of such things as Ancient Egyptian
  48. Heiroglyphics, where it seems the art work is intimately involved with the
  49. meaning; I can't argue, however, that Aramaeic and other dead written
  50. languages should probably be represented.  This was the justification for
  51. moving to 32 bits suggested in the Unicode Volume II.  One wonders at the
  52. amount of memory necessary to store such a font.
  53.  
  54. |> I personally would vote for support of 32-bit characters rather than 
  55. |> Unicode, if anyone is able to scare up the docs on the proposed 32-bit
  56. |> character standard.  This would allow Linux to avoid the comming
  57. |> difficulties with chinese/japanese font collisions, and also keep it
  58. |> out on the leading edge, rather than following Microsloth's somewhat ...
  59. |> ah ... shall we say, questionable leadership in this area.
  60.  
  61. I believe the "collision problem" has been vastly overstated, unless you mean
  62. that there actually exist multiple Unicode fonts with different glyphs at the
  63. same lexical locations; I don't believe this is the case.
  64.  
  65. It is a basic assumption that input, if not also output, will require some
  66. type of localization; it is equally likely that there will be few mixed
  67. language mechanisms, and that such localization will need to be done on the
  68. basis of a per tty method, if nothing else, to provide for the message
  69. catalog translators.  Since we are not directly bound to a graphic
  70. environment, I don't think it is possible to designate a widget/device as
  71. that mechanism unless we are willing to give up text-only devices entirely.
  72. Similarly, the lack of a streams mechanism makes it unlikely that a pure tty
  73. environment will suffice for the translation process.  If this is accepted,
  74. the collision problem, as I see it, is non-existant.
  75.  
  76.  
  77.                     Terry Lambert
  78.                     terry@icarus.weber.edu
  79.                     terry_lambert@novell.com
  80. ---
  81. Any opinions in this posting are my own and not those of my present
  82. or previous employers.
  83. -------------------------------------------------------------------------------
  84.                                         "I have an 8 user poetic license" - me
  85.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  86. -------------------------------------------------------------------------------
  87.