Re: Cross-platform e-mail text size problems

In article <g4atm1$eh6$1@xxxxxxxx>, AV3 <arvimide@xxxxxxxxxxxxx> wrote:

Sander Tekelenburg wrote:

[...]

"Plain text" has nothing to do with character repertoires. [...]

My friend Google, sending me to Wikipedia, suggests the relationship to
ASCII that I referred to.

The way I read <http://en.wikipedia.org/wiki/Plain_text>, ASCII is
mentioned mostly as historical reference. I don't see it suggest that
ASCII is more "plain text" than Unicode. It says that "plain text" used
to require ASCII (and never one of the 'high ascii' variants we were
stuck with before Unicode) and goes on to explain how Unicode is
replacing ASCII in plain text.

But I can see how the IMO too prominent placement of the 2nd and 3rd
paragraph can be misleading. Would fit better under "encoding" or
"history".

When Apple began implementing Unicode, only
.rtf-documents could preserve formatting with diacritics beyond the
range of Latin 1; .txt-documents showed gobbledegook for characters
beyond the first 256 of Unicode.

Sounds like a situation where the underlying system is not Unicode. It's
probably easier to take something like RTF and wrap "special characters"
in it, than making the entire (file) system Unicode savvy.

In any case, this seems anecdotal. It just tells us that one implementor
made use of RTF to hack some sort of Unicode support into a non-Unicode
aware system.

I haven't checked since those early
days, always formatting for .rtf, .doc, etc., and avoiding .txt.

Since Mac OS X the system has Unicode support under the hood. Text is
stored as utf-16 by default. (Individual apps might of course still not
support Unicode properly.)

[...]

Has plain text been upgraded without my noticing?

If you define "plain text" as "non-formatted", encoding is irrelevant.

If you define "plain text" as "lowest common denomiator", I suppose you
could say that it has indeed been upgraded from ASCII to Unicode, thanks
to Unicode having become ubiquitous enough to be considered a "low
enough common denominator".

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
.

Relevant Pages

  • Re: CFile::Read problem ???
    ... As far as the C compiler is concerned, ... you can pretty much always assign a char ... as ASCII and wchar_t as Unicode. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Opening a text file that may be ASCII *or* Unicode
    ... It could well be ASCII empty -- no bytes.) ... UTF & BOM ... Positively Must Know About Unicode and Character Sets ... > regards, Andy ...
    (microsoft.public.scripting.vbscript)
  • Re: Cross-platform e-mail text size problems
    ... ASCII is mentioned mostly as historical reference. ... It says that "plain text" used to require ASCII (and never one of the 'high ascii' variants we were stuck with before Unicode) and goes on to explain how Unicode is replacing ASCII in plain text. ... If you define "plain text" as "lowest common denomiator", I suppose you could say that it has indeed been upgraded from ASCII to Unicode, thanks to Unicode having become ubiquitous enough to be considered a "low enough common denominator". ...
    (comp.sys.mac.apps)
  • Re: Format of string output of a socket server
    ... ASCII is the same no matter what byte encoding is used. ... By definition any ASCII string is in UTF-8 encoding. ... The client program can then convert to Unicode or whatever they see fit? ... I am writing a socket server to deliver telephony events to clients on ...
    (microsoft.public.win32.programmer.networks)
  • Re: How do I save a word document to a floopy disk?
    ... ASCII seems to be a Windoze thing these days - Tiger does not appear to have ... Under the Mac OS you don't hold down Alt and key in a number on the numerical ... Character Palette. ... Under OS X they are Unicode only and my news-reader does not support them. ...
    (microsoft.public.publisher)