wsflinn@violet.waterloo.edu (Scott Flinn) (10/27/88)
Many months ago, I grabbed a ~130K text file from rec.arts.startrek
which, when printed properly, is a picture of the Enterprise. I
have printed this without any problem using the standard desktop
utility (ie. double click on non-program file and select PRINT),
and using the 'cat' command inside MWC microshell (msh). No
problems yet.
The trick is that the picture is enhanced by printing each line
3 times, which produces many overstruck characters. My own naive
attempt to print this picture (basically using fgetc() and fputc(),
or fgets() and fputs(), Bconout(), etc.) fails miserably. It prints the
first pass of the line, some x's at the right and left margin, and
ignores the remaining characters. Each line in the file has >200
characters ... the characters which are overstruck on each line
are simply separated by spaces (ascii 32's), not '\r's ... and each
line ends with '\n'. What are the printing programs doing with
these lines. Are they breaking them into 3 smaller '\r' separated
lines (how do they know the line length)? I'm lost ... help.
Incidentally, the picture must be printed in 132 column mode.
I eagerly anticipate the excrutiating embarrassment of a reply.
--------------------------------------------------------------------
Scott Flinn: one of these may work wsflinn@violet.waterloo.edu
wsflinn@violet.waterloo.cdn
wsflinn@violet.uwaterloo.ca
watmath!violet!wsflinnto_stdnet@stag.UUCP (10/29/88)
From: omni!emh@stag.UUCP (Eric Hopper) wsflin writes: > wsflin in <9328@watdragon.waterloo.edu> > The trick is that the picture is enhanced by printing each line >3 times, which produces many overstruck characters. My own naive >attempt to print this picture (basically using fgetc() and fputc(), >or fgets() and fputs(), Bconout(), etc.) fails miserably. It prints the >first pass of the line, some x's at the right and left margin, and >ignores the remaining characters. Each line in the file has >200 >characters ... the characters which are overstruck on each line >are simply separated by spaces (ascii 32's), not '\r's ... and each >line ends with '\n'. > Depending on which version of C your using, the characters may be being sent in "translated mode." The reason for this is the fact that printers like \r\n for a newline, while the screen only likes \n. The "translated mode" usually adds a \r for every \n going out, and strips all of the \r's coming in. You can usually get around this translated mode with a flag in your open command. I use Laser C, and to get around translated mode you have to do something like: FILE *open_file(fnme) register char *fnme; { FILE *file; /* The b flag sets it to "binary" or untranslated mode. */ if ((*file = fopen(fnme, "br") == NULL) fprintf(stderr, "Error in opening file %s.", fnme); return(file); } for low-level access: int open_file(fnme) register char *fnme; { int file; /* The O_BINARY flag sets it to "binary" or untranslated mode. */ if ((file = open(fnme, O_RDONLY | O_BINARY)) == -1) fprintf(stderr, "Error in opening file %s.", fnme); return(file); } Since you report the error even when using GEMDOS/BIOS/XBIOS routines which have no such filtering, I think the problem must be in opening the file to be output. Eric Hopper (Omnifarious) Don't try to send to omni, as it is completely unkown to any system except stag. omni!emh@stag.UUCP or ....!pwcs!stag!omni!emh /*****************************************************************************/ /* All opinions presented here are the result of my enviroment, or heredity. */ /* If you don't like them you only have yourselves or my parents to blame. */ /*****************************************************************************/ ____ \* "I went insane to */ _ /. .\ \* preserve my sanity */ /\ / ( \/ ) /\/\ |/\ . \* for later." */ | _ _ \ \____/ | | | | | \* Ford Prefect */ --- / \ |/\ . / \ | | \ \****************/ | \_/\ | | \_/ \_/\ _/ /****************************************************************************/
kirkenda@psu-cs.UUCP (Steve Kirkendall) (10/31/88)
In article <9328@watdragon.waterloo.edu> wsflinn@violet.waterloo.edu (Scott Flinn) writes: > > The trick is that the picture is enhanced by printing each line >3 times, which produces many overstruck characters. My own naive >attempt to print this picture (basically using fgetc() and fputc(), >or fgets() and fputs(), Bconout(), etc.) fails miserably. It prints the >first pass of the line, some x's at the right and left margin, and >ignores the remaining characters. Each line in the file has >200 >characters ... the characters which are overstruck on each line >are simply separated by spaces (ascii 32's), not '\r's ... and each >line ends with '\n'. What are the printing programs doing with >these lines. Are they breaking them into 3 smaller '\r' separated >lines (how do they know the line length)? I'm lost ... help. Just a guess, but I'd say the file I/O functions in your compiler's library are stripping out all carriage returns. Atari compilers usually do this to convert text files from Atari format (Which ends each line with a carriage-return/line-feed pair) to Unix format (which ends each line with just a carriage-return) so that programs can be ported from UNIX to the ST more easily. You're going to have to disable this conversion by openning the file as a "binary" file. With the old Megamax compiler, this is done by beginning the file mode string with a 'b', as in: fp = fopen("STARTREK.PIC", "br"); ^-- Notice the 'b' Hope that helps. -- Steve Kirkendall