home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / internat / 937 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  2.3 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!att!allegra!alice!andrew
  2. From: andrew@alice.att.com (Andrew Hume)
  3. Newsgroups: comp.std.internat
  4. Subject: Re: Data tagging (was: 8-bit representation, plus an X problem)
  5. Summary: que?
  6. Message-ID: <24494@alice.att.com>
  7. Date: 28 Dec 92 06:39:52 GMT
  8. Article-I.D.: alice.24494
  9. References: <24426@alice.att.com| <1gpruaINNhfm@frigate.doc.ic.ac.uk> <2563@titccy.cc.titech.ac.jp>
  10. Organization: AT&T Bell Laboratories, Murray Hill NJ
  11. Lines: 40
  12.  
  13. In article <2563@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
  14. > In article <24479@alice.att.com>
  15. >     andrew@alice.att.com (Andrew Hume) writes:
  16. > >japanese better get rendered as japanese no matter what your locale is.
  17. > 
  18. > I heard that, microsoft's NT will have a locale mechanism so that
  19. > it can print Japanes Han as Japanese and Chinese Han as Chinese,
  20. > which is impossible with bare 10646/Unicode.
  21.  
  22.     this is a fundamental and persistent misapprehension of
  23. 10646. it was neither designed for, nor can it allowd a system
  24. to display identical Han characters (same 10646 codepoint)
  25. in different fonts WITHOUT some other (non-10646) convention.
  26. 10646 simply defines codepoints, allowing the unambiguous specification
  27. of the characters. if you want to set (or switch) fonts, then you
  28. have to invent some scheme to do it, as say ISO 2022 does
  29. (in a slightly clumsy way).
  30.     i claim NT has some convention in addition to the locale
  31. (perhaps, it is part of the lcoale's definition) so it can do this.
  32. but i don't know.
  33.  
  34. > >another example is the issue of system error messages; what language
  35. > >(for example) should they be in?
  36. > 
  37. > Shouldn't we use error numbers internally and interprete it by local
  38. > programs?
  39.  
  40.     we couldn't figure out a way to do that in plan 9.
  41. the problem is that a file server, say, may have an arbitrary
  42. number of error conditions, many of which may not be known locally.
  43. originally, plan 9's file system protocol returned numbers for
  44. errors but part of the protocol was getting the text messgae for an
  45. error number (so you could cache these lcoally in a program).
  46.     when the protocol was updated, this was taken out
  47. and errors are now just text strings (64 bytes i think).
  48.  
  49.     the bottom line is, when you connect to remote services,
  50. there is simply no way to know what they might report as errors.
  51.  
  52.     andrew
  53.