Hello again! This month's subject was suggested by JOAN RYAN, who points out that many Atarians are confused by the difference between a file's being SAVEd ASCII and its being PRINTed to disk.
SAVING A FILE
First let's review how AtariWriter Plus ordinarily SAVEs a file when you select [S] from the menu screen. First you are prompted for a filename. (If the file has been LOADed from disk, the filename under which it was previously SAVEd is given. If you intend to SAVE to the same file, just hit [RETURN]. There is no need to retype the filename.) Now before any text is sent to the disk drive, all the commands from the Global Format screen, together with the TAB settings for the file, are SAVEd to disk. These instructions are then followed by your text.
SAVING ASCII
If your file is going to be loaded into an Atari (8-bit) word processor other than AtariWriter Plus, all these instructions at the beginning of the SAVEd file will probably be meaningless (at best) or even destructive (at worst) to your file when loaded into the other word processor. Therefore, you should SAVE the file by hitting [CONTROL-S] from the menu. This way you SAVE only the ASCII text as seen on the edit screen with none of the initial formatting instructions which are ordinarily SAVEd.
Watch out for in-text instructions, such as margin changes, underlining, eject page, etc., which WILL be SAVEd along with the text. These commands will very likely not be understood by the other word processor and should be deleted before the SAVE ASCII. When the stripped file has been loaded by the other word processor, it can be reformatted as necessary.
If the file is being prepared for transfer to a word processor on a non-Atari (8-bit) computer, an extra step must be performed before the SAVE ASCII. In a previous column I explained how to change each Carriage Return (ATASCII 155) to the ASCII 13 + 10 that is expected by most other computers. If you neglect this step, the file may be received by the other computer as corrupted.
PRINTING TO DISK
The third way of transferring a file from memory to disk is by PRINTing it to disk. (Hit [P] from the menu, answer [N] to "PRINT TO PRINTER, Y/N ?" and enter filename.) Unlike the SAVE ASCII discussed above, this does not strip formatting commands from the file. Rather they are interpreted according to the printer driver being used. The resulting file will probably be longer than the same file SAVEd to disk, the extra length mostly comprised of formatting spaces.
When you instruct AtariWriter Plus to print with a Left Margin of 10, it does not send the code for Left Margin to your printer. Instead it actually sends 10 spaces before each and every line of text. When instructed to center a line, AtariWriter Plus calculates how many initial spaces will achieve this and prints that many spaces before the text. Likewise a top and bottom margin of 6 lines will result in a file with 12 Carriage Returns between pages. Footers and Headers (even page numbering) will appear in the file just as they will appear on paper.
This means that if you prepare documentation for a program and PRINT it to disk, anyone can have printed docs without using a word processor at all. He or she merely copies the file from the disk to any printer. For example, from the Atari DOS 2.5 menu, select [C], then type
D:filename.doc,P:
using the name of the doc file as the filename.
A word of warning (you knew there would be one, didn't you?): Some in-text commands ARE issued to the printer using the printer's own commands for the function as designated in the printer driver. Included among these are underlining, italics, double-wide (elongated) print, etc. It's best not to use any of these commands if you are planning to PRINT to disk. If you are using an Epson printer driver, but the user of the PRINTed-to-disk file has an Okidata printer, he or she will likely get unexpected results when copying the file from DOS. It's safe to use any command that specifies spacing in some way, but don't use any commands that change the font - either in size or style.
By the way, I noticed that the columnar material in last month's column was definitely not lined up perfectly as it was in my ASCII file. This is because the article was printed in a proportional font. (NOTE TO THE EDITOR: There is no way I can allow for this. However, I think YOU might be able to edit this type of material before printing if you have the time.)
