home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / bsd / 10297 < prev    next >
Encoding:
Text File  |  1992-12-16  |  6.5 KB  |  141 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: INTERNATIONALIZATION: JAPAN, FAR EAST
  5. Message-ID: <1992Dec16.221634.4879@fcom.cc.utah.edu>
  6. Keywords: Han Kanji Katakana Hirugana ISO10646 Unicode Codepages
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: Weber State University  (Ogden, UT)
  9. References: <1992Dec14.185028.9757@fcom.cc.utah.edu> <1gksolINNmkg@frigate.doc.ic.ac.uk> <mathias.724467456@sune.stacken.kth.se>
  10. Date: Wed, 16 Dec 92 22:16:34 GMT
  11. Lines: 128
  12.  
  13. In article <mathias.724467456@sune.stacken.kth.se> mathias@stacken.kth.se (Mathias Bage) writes:
  14. >In <1gksolINNmkg@frigate.doc.ic.ac.uk> kd@doc.ic.ac.uk (Kostis Dryllerakis) writes:
  15. [ ... Re: INTERNATIONIZATION ... ]
  16. >>        Preliminary attemps have already been made (I personally work
  17. >>under X-windows with greek ISO-standard characters without many
  18. >>problems) but a coordinated effort for internationalisation is indeed
  19. >>necessary. Note that the rest of the operating systems are currently
  20. >>"externally touched" in order to support the greek language i.e.  bu
  21. >>hacking your way out.
  22. >
  23. >  Has anyone in this newsgroup ever heard of the Unicode/ISO10646
  24. >(UCS) standard?  It exists today and has everything (almost), even
  25. >though the Japanese don't like the sort order of the Kanji
  26. >characters...  Look/ask in comp.internat.std for more info.  See also
  27. >RFC 1345.
  28.  
  29. I mentioned Unicode as the proposed 386BSD target  standard, with ISO
  30. character set attribution on specific files *within* the file system
  31. as a means of avoiding eating huge chunks of storage in languages
  32. with existing 8-bit representations (ie: the to/from translation would
  33. be done in a file system layer (perhaps the VFS syscall layer) common
  34. to all file systems).
  35.  
  36. I would be more likely to endorse Unicode than the 10646 draft standard
  37. (which includes Unicode) simply because ISO-10646 *is* draft.
  38.  
  39. Unicode (from 5 of the 7 responses garnered so far) is pretty much
  40. uniformly hated in Japan; the Japanese seem to prefer the JIS encoding
  41. (ala kterm and jterm).  While this *is* embodied in an existing
  42. standard (XPG4), it has the drawback of preventing a unified character
  43. glyph space, such as that provided by Unicode.
  44.  
  45. I suspect this preference stems from the existing equipment, state
  46. tables, and IBM VGA support for JIS more than any real prejudice
  47. against the standard for technical reasons.
  48.  
  49. The unvarnished facts are:
  50.  
  51. 1)    Microsoft NT is Unicode based.
  52. 2)    Unicode provides a ROMable X font (we'd have to build one;
  53.     it's actually the fact of the non-overlapping glyph space
  54.     that provides an advantage over JIS).
  55. 3)    Unicode provides a means of simultaneous storage of multilingual
  56.     documents on the same system.
  57. 4)    Use of Unicode within the file system's directory service name
  58.     space provides a means of internationalizing 386BSD itself.
  59. 5)    A "Unicode outline font" project is currently under way in
  60.     China.
  61. 6)    Unicode allows for "localization ready" as opposed to simply
  62.     "internationalizable" UNIX tools and utilities.
  63. 7)    Fixed field lengths are observed in utilities/programs regardless
  64.     of the localized language (ie: 80 English characters=80 Greek
  65.     characters=80 Cyrillic characters=80 Kanji characters).  A runic
  66.     implementation would cause field lengths to vary, peraps radically.
  67. 8)    Support for nearly all written human languages, with a proposed
  68.     expansion for a larger set.
  69.  
  70. The drawbacks are:
  71.  
  72. 1)    Non-compliance with XPG4.
  73. 2)    Probable non-compliance with ISO-10646 (due to it being incomplete).
  74. 3)    Japaneese engineers don't like it (probable reason: current JIS
  75.     investment in man hours/money).
  76. 4)    "Connection rules" For languages (like Tamil and Arabic) do not
  77.     translate readily into X display technology.
  78. 5)    A rewrite is necessary for most of the JIS input tables and
  79.     semantics to give an identical key sequence/Kanji presentation
  80.     for Japanese.
  81.  
  82. The arguments are:
  83.  
  84. 1)    Non-compliance with XPG4 is not a problem, since it is impossible
  85.     to comply with both XPG4 and ISO-10646.
  86. 2)    By utilizing the ISO-10646 draft, conflicts with the completed
  87.     standard can be minimized.
  88. 3)    This is sticky.  If the reason Japanese engineers dislike Unicode
  89.     is simply embedded technology (JIS/XPG4-JIS), then we don't have
  90.     a problem... the technology used should not be apparent to the
  91.     user in any case.  If the JIS technology is preferred over the
  92.     Unicode technology because of engineering simplification for
  93.     romanji/kana conversion to kanji, then the problem is a little
  94.     more difficult, but is surmountable with ~16K of conversion
  95.     vector tables (small overhead compared to the memory taken by a
  96.     single font).  If the JIS ordering is preferred because it aids
  97.     in stroke-count analysis for symbol recognition, *then* we have
  98.     a problem.
  99. 4)    Connection rules for, for instance, Tamil, can not be resolved
  100.     adequately using any of the existing character technologies for
  101.     X; thus it is not at issue.
  102. 5)    A rewrite will be necessary for these tables regardless, even were
  103.     we to choose XPG4-JIS encoding, if only because the encoding is
  104.     going to vary when the character tables are offset to form a
  105.     Unicode-like non-intesecting glyph set (necessary for "localization
  106.     ready" as opposed to "internationalizable" OS and tools).
  107.  
  108. Definitions:
  109.  
  110.     localization ready:    Missing per-locale translation of text
  111.                 strings.  All work has been done to
  112.                 display drivers & environment to support
  113.                 drop in message databases in the local
  114.                 language.
  115.  
  116.     internationalizable:    Missing per-locale translation of text
  117.                 strings.  Missing OS/FS support for
  118.                 local language representation.  May
  119.                 run "localized" apps like jterm/kterm.
  120.  
  121.  
  122. A significant advantage of a "localization ready" OS is the ability to
  123. supply a "default" environment through a static which is modified by
  124. examination of the "LOCALE" or other language specification mechanism
  125. in the user's environment.  Thus all applications written on the
  126. system are already "enabled" by virtue of their use of the C library;
  127. this assumes use of "unichar" types, etc., within the applications.
  128.  
  129.  
  130.                     Terry Lambert
  131.                     terry@icarus.weber.edu
  132.                     terry_lambert@novell.com
  133. ---
  134. Any opinions in this posting are my own and not those of my present
  135. or previous employers.
  136. -- 
  137. -------------------------------------------------------------------------------
  138.                                         "I have an 8 user poetic license" - me
  139.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  140. -------------------------------------------------------------------------------
  141.