tr problem

[Les]

Actually early print programs just dumped files to the line printer (a
teletype or actual row printer).  Thus the file had to contain the whole
information.  At the time, no one could forsee the situation we have
today of displays which do vector, rastor, bit mapped, and so on.
Moreover, as time goes on, we will find issues with todays file formats
in dealing with 3d or immersive displays, or even displays in some as
yet undefined multidimentional/multisensory format.  No one can forsee
the future.  

	And while I dislike the issues with text presentation that occur, I do
understand the history of it, and the issue of backward compatibility.
You might find it entertaining to look up some of the history of text
editors some time, and certainly informative.

	But as to the format vs the display, they are never fully independent,
although software vendors and standards organizations do make heroic
efforts.  

	And by the way, these issues are not restricted to text.  You might be
interested in the issues confronting the virtual reality folks now, as
VR seems to be the next WEB killer ap.  The avatars, the avatar
properties, avatar characteristics, avatar wardrobes and actions all are
facing similar issues, where it is impossible for some one to establish
an on line personna that will move freely between VR environments.  This
is similar to the text issue, because for it to be solved the definition
of what is needed for correct file representation and what is needed by
each application must be resolved before a comprehensive design will be
able to be standardized to move between worlds.  Perhaps with your great
insight you might provide the Second Life, VRML, Croquet, Cobalt, WOW,
and others with valuable information on standardization?

Regards,
Les H
On Sat, 2008-06-14 at 08:27 -0430, Patrick O'Callaghan wrote:
> On Sat, 2008-06-14 at 20:38 +0930, Tim wrote:
> > On Sat, 2008-06-14 at 19:24 +1000, Cameron Simpson wrote:
> > > A line _should_ be terminated by a single character. What that character
> > > is is a somewhat arbitrary choice, given that the ASCII table doesn't
> > > have an end-of-line (EOL) character, just CR and LF and ASCII was what
> > > was there the play with. UNIX went with NL, OS/9 and Macs went with CR,
> > > and DOS went with "I'm too dumb to translate text delimiters into
> > > printer control actions", thus its CR/NL overspeak.
> > 
> > Considering that the display of text files is still done over terminals
> > where the ability to return to the beginning of the same line and
> > overwrite, is a useful feature, there's value in the end of line having
> > separate line feed and return characters.  Not all display of text is of
> > static text.
> 
> I couldn't agree less. The whole root of this problem is mixing up two
> completely separate concepts: how to mark an end of line, and how to
> display text on some device.
> 
> poc
>