home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / bsd / 9237 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.1 KB  |  85 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!gatech!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: Re: multibyte character representations and Unicode
  5. Message-ID: <1992Nov23.193620.9513@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <721993836.11625@minster.york.ac.uk>
  9. Date: Mon, 23 Nov 92 19:36:20 GMT
  10. Lines: 73
  11.  
  12. In article <721993836.11625@minster.york.ac.uk> forsyth@minster.york.ac.uk writes:
  13. >Terry Weber suggests that half one's disc space will vanish
  14. >on adopting Unicode.  Not so: I draw your attention to Plan 9,
  15. >which uses Unicode very successfully.  See the Plan 9 documentation
  16. >on research.att.com (dist/plan9doc, I think).
  17.  
  18. If you are talking about truly using the Unicode standard, then you are
  19. talking about using 16 bits for English characters instead of 8 bits.
  20. While your disk space wouldn "disappear", it would be halved, unless you
  21. mixed storage of Unicode and ASCII on the same disk.
  22.  
  23. Unicode contains a total of 34,348 characters.  This is 52% of the largest
  24. number of characters representable in 16 bits (65536), and is also larger
  25. than what can be represented with conditional multibyting (8th bit set on
  26. first character indicating multibyte, otherwise 7 bit ASCII), which is
  27. 32,896 characters (128 + 128 * 256).
  28.  
  29. It seems to me that Unicode representation on disk requires 2 bytes per
  30. character (symbol).  Thus a document file in English that used to tak
  31. 2K stored in ASCII would take 4K (2K symbols * 2 bytes per symbol) to
  32. store in Unicode.
  33.  
  34. >Eventually Plan 9 switched to a new encoding -- which apparently has now been
  35. >proposed for use in ISO 10646 -- that lacks all the unfortunate features.
  36. >The second and third bytes of the encoding do not look like ASCII characters.
  37. >(All bytes of an encoded character have the 0x80 bit set.)
  38. >The consequence is that even fewer programs are affected:
  39. >most pass Unicode encodings straight through.
  40.  
  41. This isn't really Unicode unless it follows Unicode encoding, and it lacks
  42. the ability to provide a fixed size per symbol storage mechanism, but I
  43. agree that ISO 10646 is a real possibility, although it seems rather English
  44. centric.
  45.  
  46. In X, to provide an 8x8 Unicode font, it takes 274784 bytes of storage for
  47. the actual font glyphs, plus overhead; a 10x20 takes 1030440 (just under a
  48. Meg, assuming the overhead is less than 18K).  Both could easily be done in
  49. ROM.
  50.  
  51. Without multibyte encoding (ie: straight 16 bit multibyte), the output is
  52. straightforward using X.  The same is true for an "English-only" or other
  53. ("Cyrillic -only", etc.) font, since X fonts are allowed to be sparse;
  54. thus the full Unicode font is only necessary for multinational use of the
  55. same device... even then, the amount of glyphs in a font need only be
  56. enough to intersect both sets.
  57.  
  58. Thus, in many cases, font-fill centric encoding (ie: this is the font I used,
  59. and these are the 8 bit representations of the Unicode characters lexically
  60. within the font) is sufficient to provide 8 bit storage for all but Kanji.
  61. If the Japaneese could limit themselves to Kana (Katakana/Hirugana), then
  62. they could also benefit from this storage technique as well (this would
  63. also go a long way towards making them compute-competitive and reduce the
  64. hoops one jumps through when using a Kanji keyboard).
  65.  
  66. >In particular, the `normal' file system names can hold Unicode
  67. >characters without fuss.  There is certainly no need to switch to 16-bit
  68. >representations for them, with all that that entails.
  69.  
  70. No argument here; however, I would say that picking a font-fill encoding
  71. as a file storage attribute would be sufficient for this as well.
  72.  
  73.  
  74.                     Terry Lambert
  75.                     terry@icarus.weber.edu
  76.                     terry_lambert@novell.com
  77. ---
  78. Any opinions in this posting are my own and not those of my present
  79. or previous employers.
  80. -- 
  81. -------------------------------------------------------------------------------
  82.                                         "I have an 8 user poetic license" - me
  83.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  84. -------------------------------------------------------------------------------
  85.