home *** CD-ROM | disk | FTP | other *** search
/ ftp.ulg.ac.be / 2014.06.ftp.ulg.ac.be.tar / ftp.ulg.ac.be / pub / docs / iso8859 / readme2.txt < prev   
Text File  |  1998-05-17  |  4KB  |  62 lines

  1. Comments (best understood after reading iso8859.networking.txt)
  2.  
  3. The documentation in this directory started to be written in the early 90s.
  4. At that time, it was not widely obvious that, and how, text data had to be
  5. translated in communication to cope with different character sets in hosts.
  6. The theory and translation tables have now gained wide acceptance, especially
  7. the translation table for the Macintosh.
  8.  
  9. There remains a big problem, though.
  10. As clearly stated, the scope of the paper is limited to 8-bit character sets
  11. on communication lines, and an 8-bit character set is limited by nature.
  12.  
  13. The best understood example is the case of the Macintosh.
  14. I have received various comments that Macintosh translation could be different. 
  15. These comments are perfectly right: there are billions of ways to make another
  16. translation table just as good as mine because a large part of it is arbitrary.
  17. The comments always related to the arbitrary part, only designed to be unique
  18. so that Macintosh to Macintosh communication doesn't alter data.
  19. Never a word about the other part.
  20. So, guess why...
  21.  
  22. The reason is that ISO 8859-1 is a well established communication standard and
  23. hence that no one questions the part of the Macintosh table adhering to it.
  24. The problem is that there simply is no undisputable way to transmit the rest of
  25. the Macintosh characters on a communication line.
  26. Oh yes, as strange as it may sound, there is still no way for a Macintosh to be
  27. a full network computer regarding character sets by the end of this century.
  28.  
  29. For example, there is an "oe" character both on the Macintosh and on Windows
  30. (ligature oe is a single character).
  31. No one in the world will ever agree on what code point must be used on the
  32. communication line to send this character from the Macintosh to Windows or
  33. conversely unless something other than ISO 8859-1 is used on the communication
  34. line. The UNAVOIDABLE conclusion is that a character set wider than 8 bits HAS
  35. to be used in communication for the Macintosh to become a network computer.
  36.  
  37. This wider network character set IS there to be used in the form of ISO 10646,
  38. aka its subset called UNICODE, with their encodings. If THAT were used, no one
  39. would ever think of wondering how a Macintosh must transmit "oe". And this
  40. holds for any character of any character set that can be used on anu computer.
  41.  
  42. When discussion was going on about MIME's encoding of character sets, I stated
  43. loudly that it was a key matter to use 10646 exclusively in mail. Alas, 10646
  44. was regarded not ready, and a menagerie of 8-bit character sets resulted.
  45. I've been happy to volunteer and contribute the evolution of international
  46. characters transmission, but doing that with an 8-bit character set has soon
  47. been a pain in my heart because I knew that I was slowing down the emergence of
  48. the only true solution.
  49. So, before sending me comments about my 8-bit Mac translation, please think
  50. twice if you wouldn't prefer using ISO 10646, and maybe send comments to those
  51. whose real job is to design communication and ask them for ISO 10646.
  52. People from the ISO standards have done a extremely good job with 10646.
  53. Others like authors of Web browsers have put it to good use.
  54. But translation is normally not an application feature, but part of the
  55. presentation layer of the OSI model, and hence of the system, and the grand
  56. solution will be be put together when ftp will translate text as easily as any
  57. other application by invoking the same system primitives.
  58.  
  59. Heartfelt thanks for your interest,
  60.  
  61. AndrΘ (C3A9, not E9), May 1998.
  62.