home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / bsd / 8962 < prev    next >
Encoding:
Text File  |  1992-11-17  |  6.7 KB  |  131 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!spool.mu.edu!wupost!usc!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: [386bsd] INTERNATIONALIZATION (was can't deal with 8-bit input)
  5. Message-ID: <1992Nov16.232035.6307@fcom.cc.utah.edu>
  6. Summary: Going global
  7. Sender: news@fcom.cc.utah.edu
  8. Organization: Weber State University  (Ogden, UT)
  9. References: <1992Nov16.081801.15019@kum.kaist.ac.kr>
  10. Date: Mon, 16 Nov 92 23:20:35 GMT
  11. Lines: 118
  12.  
  13. In article <1992Nov16.081801.15019@kum.kaist.ac.kr> jbkang@csking.kaist.ac.kr (Joongbin Kang) writes:
  14. >  ...But another problem occured during using the 'hanterm', Korean version
  15. >  of xterm. It can display Korean texts with MSB set (the same to most
  16. >  oriental languages, such as kanji etc), but I couldn't input Korean text.
  17. >  Hanterm itself provides Korean input automata, and it should work well
  18. >  with X11R5. Another test shows that kernel seems to have trouble with
  19. >  multibyte characters.
  20. >    % cat
  21. >    test
  22. >    test (echoed to tty)
  23. >    ^D
  24. >    % cat
  25. >    xxxx(entered korean characters -- it can be seen when typing)
  26. >    (but no echo to tty!)
  27. >    ^D (this DIDN'T work)
  28. >    ^C
  29. >    %
  30. >  So, what's the problem? If I cannot use hangul in 386bsd, it loses
  31. >  practicality...Help!
  32.  
  33. Most likely, the echo to your X term was broken when it sent you back
  34. your characters... seriously!
  35.  
  36. The default cflags for a tty in 386BSD strip parity (the 8th bit) by
  37. setting cs7 and setting even parity (-parodd, parenb), and setting the
  38. iflag istrip.  The fact that you got the characters you typed back at
  39. all is an indicator that istrip wasn't working on echoed characters.
  40.  
  41. An additional problem with ANSI teminal emulation, if not internationalized,
  42. is the CSI characters (0x80-0x9f) which are seen as <ESC> + <char - 0x60>
  43. (ie 0x9b = 0x1b + 0x3b ...or... <CSI> = <ESC>[).  Basically, you have to
  44. disable this functionality to get around the problem with 0x80-0x9f range
  45. characters.  SCO "gets around" the problem by allowing the output of the
  46. characters in this range with an escape sequence to pick the character
  47. set in that range instead of the normal output (<ESC>[12m ?  It's been
  48. about 3 years since I wrote the SCO color console emulator for TERM from
  49. Century Software.  Doing it this way get you a PC character set on your
  50. console, but it is hardly 8-bit clean.
  51.  
  52. Hangul, like the Japaneese Katakana and Hirugana, is representable in an
  53. 8 bit set, the lower 128 characters being ASCII.  Unless you are tryingtrying
  54. for Unicode, you should not need multibyte -- even then, you only need 16 bits,
  55. not the 32 bits Sun is currently using for their Internationalization.
  56.  
  57. Get the echoing working with cat by setting your terminal modes correctly,
  58. and you should be able to type in 8 bit characters using the input
  59. automata (or even more clever, use a korean keyboard with one of the magic
  60. unused shifts (like alt or compose) to get the English characters for
  61. programming -- with an X terminal, the means to do this are provided in
  62. the xmodmap utility.
  63.  
  64. I don't understand "kernel seems to have trouble with multibyte characters".
  65. If by this, you mean the file system (trying to use 16 bit characters in
  66. a file name), you are correct: the file system doesn't understand this type
  67. of representation, epecially for characters in the 0-255 range, since they
  68. will have initial leading NULLs and there is no provision in the kernel or
  69. shells for byte-count prefixed multibyte strings with NULLs in them.
  70.  
  71. If you mean that you could not use 8-bit characters in a file name, then
  72. the fault lies in the input mechanism (your shell, if it isn't 8 bit clean,
  73. or your tty modes if it is).
  74.  
  75. Other than file naming (directory entry manipulation services), a stream
  76. of data is a stream of data, and the file system storing it doesn't care
  77. if it's a stream of bytes to be treated as a double-byte character set,
  78. or a stream of bytes to be treated as ASCII.
  79.  
  80. An intrinsic limiting factor in the use of Unicode or other multibyte
  81. technology within all shell tools and libraries is the fact that by
  82. doing so, you effectively halve your usable disk space (by doubling the
  83. size of the data to be stored, even if it is vanilla ASCII).  I think
  84. it will be a long time before we see large numbers of products coming
  85. out of the US which have this limitation.
  86.  
  87. One way to internationalize without falling into this trap is to adopt the
  88. ISO Latin-1 character set (usable by the majority of countries) as the
  89. standard console character set.  The "codrv" program gives us a means of
  90. providing an initial load of this onto existing video hardware.
  91.  
  92. An additional help would be the adoption of the BSD4.4 file system, in
  93. particular, the Ficus layering (ala John Heidemann), which would allow
  94. for the provision of a Unicode naming layer so that some file systems
  95. *could* be multibyte in nature.  An additional layer for Unicode disk
  96. access would probably be desirable, since this would allow cannonical
  97. representation of a text in it's native language, allowing multilingual
  98. use of the same file system without interference like one might get
  99. with one user running Latin-1 and another running Cyrillic-1.  This would
  100. allow people requiring more than 8 bits for their name space/text space
  101. to halve the size of their disk (which they would have to do anyway)
  102. without negatively impacting those of us who can live in 8 bits.
  103.  
  104. As to the other internationaization issue, which is internationalization
  105. of text strings in error messages and utilities, I think that we need to
  106. adopt the XPG3 standards for string identification, with Unicode
  107. storage of the strings (PC code page representation is for the birds).
  108. This will buy us usable error messages with little or no penalty, since
  109. the locale database can be loaded on a per-site basis (ie: I don't need
  110. to load English or Spanish if I'm German).
  111.  
  112. The limiting factor on this (in the PC market anyway) is running the
  113. display hardware in "text" mode.  Given a reliable mechanism for the
  114. identification of video hardware (maybe a non-protected mode install
  115. or portion of the boot?), the built in limitation of the IBM PC
  116. character set will become less of a consideration, at least for the
  117. 8-bit character sets which can be fully downloaded to  VGA cards.
  118.  
  119.  
  120.                     Terry Lambert
  121.                     terry@icarus.weber.edu
  122.                     terry_lambert@novell.com
  123. ---
  124. Any opinions in this posting are my own and not those of my present
  125. or previous employers.
  126. -- 
  127. -------------------------------------------------------------------------------
  128.                                         "I have an 8 user poetic license" - me
  129.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  130. -------------------------------------------------------------------------------
  131.