Re: BUG: More on C-header text files - CORRECTION
Re: BUG: More on C-header text files - CORRECTION
- Subject: Re: BUG: More on C-header text files - CORRECTION
- From: Philip Aker <email@hidden>
- Date: Mon, 01 Jul 2002 13:34:56 -0700
On Sunday, June 30, 2002, at 03:41 PM, Paul Berkowitz wrote:
I could never figure out why they needed two separate
characters for marking the ends of lines. That now makes sense.
Can you, or some else, explain or "remind" us why, when
reducing that to one character, Macs (and MS Word, even in
Windows) took CR whereas Unix ("Epoch" beginning 1/1/1970) took
LF? Why so many different implementations?
I'd like to know the real history too.
I thought that originally CRLF came about because terminals were
modelled after typewriters and had a hard-wired number of
columns (64) and a somewhat variable page height (defined by the
number of rows). In this system, the grid (actually the memory
or disk buffer which represents the grid as an array) is filled
with blanks on opening. So when the insertion point reached the
end of a line (i.e. a row) the CR would position the insertion
point to the beginning of line and the LF would then move it
down to the next row. When a character was typed into the
terminal then it actually replaced the blank that was in that
grid slot. The vestiges of this system are still present in many
Unix commands, editors, and terminals where the number of rows
and columns has to be known prior to use.
As technology advanced, the typewriter analogy became less
relevant. The notion of needing a fixed sized buffer to contain
the characters and the requirement of two characters to indicate
a line-break gave way to other models.
OK, at about this time, Gates is plundering Unix and decides
that instead of replacing the CRLF concept with a single
character, it will be re-interpreted so that a CR is used to
indicate line wrapping (i.e. a "soft" return) and that CRLF will
be a full return (i.e. a paragraph mark).
This had implications for the typesetting methods of the day
because for runtime situations, the CR could be used as a line
ending marker for screen representations (which makes for easier
redraw calculations) but didn't necessarily have to take up a
byte in the file when stored on disk. I haven't looked at M$Word
for many years but remember that I used a soft return for some
formatting purposes. For plain text files, I believe M$Word
reads/writes them in as per platform EOL convention but deals
with things internally with an approach somewhat similar to
what's been described above.
Philip
Philip Aker
http://www.aker.ca
'
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.