jimh@ultra.com (Jim Hurley) (09/13/90)
I wanted to print some overstrike graphics on my Epson-compatible. I believe I have all the dip-switches set so that isolated CR's do not linefeed. Yet I can't get this to print correctly - all CR's appear as CR/LF. I know that TOS-written records end in CR/LF, but these ASCII files were not generated by TOS. I'm not sure but I think TOS is changing the CR to CR/LF's on the way to the printer. Before I go banging my head any further: Is this correct? If so, is there a way to disable it? If TOS is at 'fault' would some kind soul explain the conditions under which this transformation occurs in general and a bit of rationalization on why? Thanks, -- Jim Hurley --> jimh@ultra.com ...!ames!ultra!jimh (408) 922-0100 Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
apratt@atari.UUCP (Allan Pratt) (09/14/90)
jimh@ultra.com (Jim Hurley) writes: >I'm not sure but I think TOS is changing the CR to CR/LF's on the >way to the printer. The send-a-character-to-a-printer part of TOS doesn't change CR to CRLF. However, the Desktop might: if you double-click the file, and say "Print" (rather than "Show" or "Cancel"), you might be seeing that. If you're running a program to send the file to the printer, you should blame that program. (The Desktop is just a program in this sense, which is why you should blame *it* if that's what you're using.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
stefan@hpbbi4.BBN.HP.COM (#Stefan Bachert) (09/14/90)
/ hpbbi4:comp.sys.atari.st.tech / jimh@ultra.com (Jim Hurley) / 1:36 am Sep 13, 1990 / > I'm not sure but I think TOS is changing the CR to CR/LF's on the > way to the printer. Before I go banging my head any further: If your assumption were true, TOS were not able to print bitmap graphics ! But You and I know TOS was able to do that ! So the only conclusion is TOS doesnot add/convert something. So you have to reconsider your previous paragraph > I believe I have all the dip-switches set so that isolated CR's > do not linefeed. Yet I can't get this to print correctly - all > CR's appear as CR/LF. Do you really can trust your files? Did you write a simple test program for that ? (eg. printf("------\r!!!!!!\n") ) Stefan
jimh@ultra.com (Jim Hurley) (09/15/90)
In <2297@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >jimh@ultra.com (Jim Hurley) writes: >>I'm not sure but I think TOS is changing the CR to CR/LF's on the >>way to the printer. >The send-a-character-to-a-printer part of TOS doesn't change CR to >CRLF. However, the Desktop might: if you double-click the file, and say >"Print" (rather than "Show" or "Cancel"), you might be seeing that. If >you're running a program to send the file to the printer, you should >blame that program. (The Desktop is just a program in this sense, >which is why you should blame *it* if that's what you're using.) >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt I solved the problem. I had been using Moshe Braner's 'more.ttp' patched into the desktop.inf for so long that I forgot about the desktop 'Show/Print..'. When I removed the more.ttp application line from desktop.inf and used the desktop print feature, the file listed correctly with overstrikes. On further investigation with some popular shells, I used BARREL (also from Moshe - gee, that guy writes some pretty useful stuff, whatever happened to him?) to capture the print output to a file and saw that all these shells had somewhere converted the CR to CRLF. Perhaps there's something in the Atari Development Libraries doing it? (assuming these shells were developed from that). If I ever get the time for trivia I'll check to see if Laser C or GNU CC have this property and report back. Thanks, to all those who e-mailed me with suggestions. -- Jim Hurley --> jimh@ultra.com ...!ames!ultra!jimh (408) 922-0100 Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
jimh@ultra.com (Jim Hurley) (10/04/90)
Well, I got considerable mail from this, and I guess I didn't word my original problem very carefully. Anyway, I have the solution and I'll explain things in a little more detail now that I have the complete picture (or at least a sharper image). Problem #1: I had patched my Desktop.Inf file so that all double clicks on non-programs would call the 'more.ttp' program from Moshe Braner. I had done this for so long now that I forgot about the Desktop Print capability. Solution #1: The Desktop Print command does indeed print in binary form and does no conversion on the input files. Problem #2: I didn't realize that TOS Shells had access to a device driver called PRN: like IBM DOS. Maybe it's just me, but I don't recall ever reading about this. Therefore, I was using shell commands like 'lpr' to do my printing. These drivers were assuming that the files ending in a single CR were UNIX-like text files and converted them for me to CR/LF. Solution #2: Use the equivalent of 'cat file > prn:' in the shell. This works fine in both gulam and MT C-Shell. -- Jim Hurley --> jimh@ultra.com ...!ames!ultra!jimh (408) 922-0100 Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134