Re: DOS Newline Character
From: Lew Pitcher (lpitcher_at_sympatico.ca)
Date: 11/24/04
- Next message: rapskat: "Re: Does Linux really Suck?"
- Previous message: B Gruff: "Re: Does Linux really Suck?"
- In reply to: Roger Leigh: "Re: DOS Newline Character"
- Next in thread: Lew Pitcher: "Re: DOS Newline Character"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 23 Nov 2004 20:31:45 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Roger Leigh wrote:
> Lew Pitcher <Lew.Pitcher@td.com> writes:
>
>
>>>Roger Leigh wrote:
>>>[snip]
>>>
>>>>Summary: CR/LF or CR or LF (or whatever your system uses) are merely
>>>>line-end markers. They don't directly correspond to any mechanical
>>>>operations, which are entirely hardware-dependent.
>>>
>>>Funny, the ECMA and ISO standards and my old ASR33 teletypewriter would
>>>disagree with you on this.
>
>
> That's true, but not all devices support those standards (ECMA-48 ?)
Those that don't support the 'dumb' ASCII print protocol do support some
'smarter' protocol. Sometimes the protocol is even backwards compatable with
'dumb' ASCII print streams. :-)
>>>Your ESC/P printer seems to act otherwise, although I believe (because
>>>of my own use of an ESC/P printer) that you are incorrect in your
>>>assertions about the ESC/P interpretation of the characters. Certainly,
>>>on my Epson LQ-570 printer, with the "CR/LF" switch set to require both
>>>carriage returns and line feeds, a 0x0d causes printing to resume at the
>>>left margin of the current line, and 0x0a causes printing to resume at
>>>the current column of the next line.
>
>
> You are correct. My assertion was from memory; double-checking with
> the ESC/P2 reference:
>
> CR: "Moves the print position to the left-margin position" (and
> flushes the line buffer)
>
> LF: "Advances the vertical print position one line" and
> "Moves the print position to the left-margin position"
> (and flushes the line buffer on 9-pin ESC/P printers only)
>
> ESC <: same as for CR, but additionally forces printing from the
> left-hand margin (i.e. unidirectionally; the default it
> b idirectional printing, so CR doesn't imply homing the head).
>
> So it's not totally in agreement with ECMA-48: LF includes an implicit
> CR, effectively making CR/LF redundant and transparently compatible
> with UNIX line endings as a happy side-effect.
This seems to be a hardware-dependant feature of certain Epson printers, and
not the /default/ behaviour for printing mechanisms.
For instance, in the handbook for my Epson LQ-570 ESC/P2 printer, it indicates
that that "auto line feed" is a switch option that, when enabled, causes the
printer to accompany each carriage-return code with a line feed. My personal
configuration for this printer is to turn this feature off. From experience, I
can tell you that, when disabled, the printer /requires/ a carriage return to
return the print head to the left margin, and /requires/ a line feed to
advance the platen to the next line (or, requires the use of the ESC/P2 escape
sequences to accomplish the same). Carriage return does /not/ perform an
implicit line feed under these conditions.
As for the definition of Carriage Return and Line Feed, the handbook says that
Carriage Return performs the carriage return, and Line Feed performs a line
feed. No qualifiers as to performing multiple functions, just CR returns
carriage to left, LF feeds paper up 1 line. For that matter the manual does
/not/ indicate that ESC < is a valid operation (obviously an older version of
the ESC/P2 protocol than you quote), in fact, it doesn't list it at all.
It appears that your ESC/P2 example is the exception, not the rule. It has,
for a long time, been the custom of builders of intellegent printers to
enhance the printers by "extending" the data stream it reads into a
"protocol". For Epson, they've added an embedded protocol introduced with
escape sequences, and called it ESC/P2. For other printer manufacturers, they
dispense with ASCII stream printing entirely, and expect that the entire data
stream will be formatted in their own specialty protocol (whether it be
PostScript or Windows Print bitmaps).
In any case, we're getting far afield from the original discussion.
Suffice it to say that, in Unix, the decision was made to logically terminate
lines with the 'newline' character, and shift the responsibility of proper
formatting to something outside of the file storage. OTOH, MSWindows defaults
to MSDOS, which defaulted to CP/M's dumb behaviour, and CP/M's behaviour was
predicated on the fact that there was no way to provide a device-independant
print management process on a (at the time) 1 MHz 8080 processor with 16Kb
memory and at most 270K disk storage (one 8" SSSD floppy disk), so text
streams were stored in the most convenient way possible, as uninterpretted
characters.
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBo+SBagVFX4UWr64RAponAKDjSgUbzPT4NhCCESAXehd5RwVW8ACdEv0Y
c1v9Py6WDiJoQGgG4azNQJw=
=Ln86
-----END PGP SIGNATURE-----
- Next message: rapskat: "Re: Does Linux really Suck?"
- Previous message: B Gruff: "Re: Does Linux really Suck?"
- In reply to: Roger Leigh: "Re: DOS Newline Character"
- Next in thread: Lew Pitcher: "Re: DOS Newline Character"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
