mat65@tukki.jyu.fi (11/29/88)
This came up when I was making a program to view MacPaint pictures on a PC
and to print them onto a printer. The program is written in C, and it uses
the standard write() call to get stuff to the printer. I open the file by
name (ie. open("/dev/prn",...)) rather than use the ready file descriptors
for printers so that the print output can easily be swiped to a disk file.
The picture is sent to a laser printer by sending an escape sequence giving
the binary picture size and the picture width in bytes, followed by the
picture data, in binary.
The problem came up when I mistakenly printed a picture on the Canon LBP-8
I use in inverted mode. Everything worked OK, except that the picture was
(of course) mostly black. Then, I inverted the picture and tried to reprint
it. It didn't print out. Mystified by this, I pressed the manual-print
button on the laser printer. Out comes a page with the picture partially
correct and partially garbled.
After lots of debugging and guesswork, I came to the conclusion that the
standard MS-DOS write interface DOES NOT ALLOW ^Z CHARACTERS TO GO OUT TO
THE PRINTER. To a file, yes. It's not the C library, I have sources for
that and there are no special-case tests for ^Z's to a printer file...
Neither is it the Centronics-printer interface, since my screen dumps often
contain ^Z's and they get printed ok on the laser.
This came up on a Unisys 500 (PC/AT MS-DOS 3.30), but also on a non-pc-clone
running MS-DOS 2.11 and a genuine IBM PC/AT under PC-DOS 3.20...
Has anybody else seen behaviour like this ?
Does anyone have an idea WHY this type of censorship has been implemented
(hello folks at MicroSoft, are u listening) ?
Otto J. Makela (with poetic license to kill), University of Jyvaskyla
InterNet: makela_otto_@jylk.jyu.fi, BitNet: MAKELA_OTTO_@FINJYU.BITNET
BBS: +358 41 211 562 (V.22bis/V.22/V.21, 24h/d)
Voice phone: +358 41 613 847
Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPEdhesi@bsu-cs.UUCP (Rahul Dhesi) (12/01/88)
In article <17693@santra.UUCP> makela_otto_@jylk.jyu.fi writes: >After lots of debugging and guesswork, I came to the conclusion that the >standard MS-DOS write interface DOES NOT ALLOW ^Z CHARACTERS TO GO OUT TO >THE PRINTER. The bug is in the printer driver, not in the write system call itself. I think this was originally intended to be a feature, but it turned out to be a bug. When you say "copy file PRN" you are really saying "copy everything in this file to my printer". But without realizing it, you are also saying "copy everything in this file that's my data to the printer, but don't copy any junk beyond the end of my data." Because of its CP/M heritage, MS-DOS's old convention was that control Z in a text file marked the end of data within the file. Many programs, using the old FCB-based system calls, created files that contained a control-Z followed by junk. Some word processors even use the junk beyond the control-Z to store their own configuration information. This is more easy to understand if you call control-Z the "end of user data" mark rather than the "end of file" mark. [This paragraph is pure speculation.] To avoid your seeing this junk when you sent such a file to the printer, the good people at Microsoft decided that the printer would simple refuse to accept anything once it saw a control-Z. For the same reason, when you do "type file" the console driver stops accepting data when it sees a control Z, sparing you seeing much junk on the screen. (Naturally, command.com has to play some tricks to make sure that output from the next command given will still show up.) What you can still do is use the IOCTL system call in MS-DOS to tell the printer to go into binary mode and accept all characters. (This is *not* the same as a file opened in binary mode from a C program.) What MS-DOS badly needs is an "stty.exe" program that will allow devices to be configured. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
mcdonald@uxe.cso.uiuc.edu (12/01/88)
To send binary files to a printer, you can do copy /b filename.ext prn: I am not sure about the following, but it agrees with my tests: the problem is in MS-DOS, not languages. It is NOT in the bios, as it is possible to write a C program with bios calls to do the copy. I still want to be able to PRINT using the MS-DOS print command, binary files. Anybody Know how? Doug McDonald
cacsc222%mx@csun.edu (12/02/88)
Re, no control Z to printer.
Make sure you open /dev/prn (or whatever) as O_BINARY...
i.e.
#include <fcntl.h>
.
.
.
fd = open("/dev/prn",O_WRITE|O_BINARY);
.
.
.
"Disclaimer? We don't need no stinking disclaimers!!!!!"
Scott Neugroschl
...!sm.unisys.com!csun!mx!cacsc222leonard@bucket.UUCP (Leonard Erickson) (12/02/88)
In article <17693@santra.UUCP> makela_otto_@jylk.jyu.fi writes:
<This came up when I was making a program to view MacPaint pictures on a PC
<and to print them onto a printer. The program is written in C, and it uses
<the standard write() call to get stuff to the printer. I open the file by
<name (ie. open("/dev/prn",...)) rather than use the ready file descriptors
<for printers so that the print output can easily be swiped to a disk file.
<stuff deleted>
<After lots of debugging and guesswork, I came to the conclusion that the
<standard MS-DOS write interface DOES NOT ALLOW ^Z CHARACTERS TO GO OUT TO
<THE PRINTER. To a file, yes. It's not the C library, I have sources for
<that and there are no special-case tests for ^Z's to a printer file...
<Neither is it the Centronics-printer interface, since my screen dumps often
<contain ^Z's and they get printed ok on the laser.
<
<Has anybody else seen behaviour like this ?
<Does anyone have an idea WHY this type of censorship has been implemented
<(hello folks at MicroSoft, are u listening) ?
The problem is simple. The answer may or may not be. You opened the file in
"cooked" (text) mode. In this mode ^Z signals end of file and ^I gets
translated into an "appropriate" number of spaces.
What you want is "raw" (binary) mode. If your language doesn't have this
choice built in, you need to play with a byte in the file descriptor.
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."swh@hpsmtc1.HP.COM (Steve Harrold) (12/02/88)
Re: CTRL-Z in printer files Whenever I want to print a file that may legitimately contain CTRL-Z characters embedded within it (e.g. raster images) I use: copy /b filename prn Works every time. -- --------------------- Steve Harrold ...hplabs!hpsmtc1!swh HPG200/13 (408) 447-5580 ---------------------
simon@ms.uky.edu (Simon Gales) (12/05/88)
In article <1156@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: > >The problem is simple. The answer may or may not be. You opened the file in >"cooked" (text) mode. In this mode ^Z signals end of file and ^I gets >translated into an "appropriate" number of spaces. > >What you want is "raw" (binary) mode. If your language doesn't have this >choice built in, you need to play with a byte in the file descriptor. I have tried to do this in RAW mode, in Microsoft C 5.0, but it does not cure this problem. I agree that it should, but I couldn't get it to work. It is probably a bug in either _setmode() or in the actual output routine. I patched around it by using the bios call for the printer, this seems to ignore tabs, doesn't add linefeeds, and passes the ^Z's on to the printer. /--------------------------------------------------------------------------\ Simon Gales@University of Ky UUCP: {rutgers, uunet}!ukma!simon Arpa: simon@ms.uky.edu MaBell: 263-2285/257-3597 BitNet: simon@UKMA.BITNET -- /--------------------------------------------------------------------------\ Simon Gales@University of Ky UUCP: {rutgers, uunet}!ukma!simon Arpa: simon@ms.uky.edu MaBell: 263-2285/257-3597 BitNet: simon@UKMA.BITNET