HOW TO PRINT TEXT IN TWO COLUMNS

- including -Some Little-Known Behavior of MAGIC WAND

by Hank Lotz

Here's a procedure for printing two-column text with the MAGIC WAND word processor. It took some development, so I outlined the procedure in hopes that the next time I needed it I could just follow it to the letter and not have to think too much. This is essentially what was used in printing this newsletter.

Two-column printing with WAND is not an automatic process; it's not a design feature. The "Supplemental User's Manual", furnished with the word processor, briefly describes how it can be accomplished, but some thought on the part of the user is still needed. I've already worked through some rough spots, so the procedure, if not automatic, is now at least mapped out. There are, however, certain requirements (things you must have, or do). The method also has limitations (things you can't do).

The Requirements:

1. A version of MAGIC WAND that has the "LINE-n" feature. (That's not a dash, it's a minus sign. The n is a numerical value.)

2. A version of MAGIC WAND that has a "hard space" recognition character. (M.W. Version 1.1 has these needed features — the book says Version 1.0 had some of the features even though it didn't document them, so you can see if yours has them by trying it.)

3. A printer that does reverse linefeeds on line. An H-14 won't work, (not with this method).

4. You must be completely finished modifying your text, i.e., ail spelling corrections must have been made, and all other editing final. More than one pass of the PRINT program is required, and if you go back to make text changes, you will have to start all over. This is probably the biggest drawback to this method, but it's not fatal. Just don't do it till you're ready to print your finished draft and you should be OK.

The Limitations;

1. Bottom margin should be at least 2 lines. It'll work as low as 1, but 2 allows operator error.

2. Method does not sweep across the page, breaking a given line into two-column components. Instead, it completes the left column of the page first, then reminds the page to print the second column. This may sound crude (it did to me) but when you actually do it, it isn't bad at all.

3. You may find other limitations in special circumstances.

This method is for printing columns with both margins justified. It should also work for ragged-right columns, but a somewhat simpler method would suffice there. You won't have to think hard to use this procedure, but I'll expand on certain aspects anyway, because if you didn't want to understand you wouldn't be reading this type of newsletter. Besides, this article is just the place to broaden the scope, and talk about WAND behavior that might otherwise never be covered.

First let's look at this "LINE n" command, as I like to call it — what does it do? If PRINT is processing line 13 and it encounters your embedded "LINE 18" command, it will move down on the paper to line 18 to output its next line. Get the idea? For another case, if you are on line 9 and you say "LINE 60", all the intervening lines will be blank and you'll print the next line way down on line 60. You don't skip any text; you just insert white space, and continue at line 60. If your page length is 66, you can't go beyond line 66. Now, let's consider another example. Suppose the printer is printing line 50, and PRINT encounters the command "LINE 11". What will happen? It'll just rewind to line 11 and print there, right? Sorry, that's the old "Right? Wrong!" ploy. MAGIC WAND PRINT will not go backwards unless you put a minus sign in the command! In the latter example, then, you should have had "LINE-11", not "LINE 11". This is easy to overlook, so watch out for it. And sure, you can dream up schemes to try to drive it nuts, but it handles itself in a nice, logical manner, and you go nuts. For example what if you were printing at 8 lines/inch, and you changed the vertical pitch at, say, line 20. There you resumed printing at 6 LPI. A feu lines later you told it to go back to line 6, i.e., "LINE-6". Can it remember that the real line 6 was printed at 8 LPI? No. The rule I worked out empirically is: LINE-n will rewind to where line "n" would have been had the whole page been printed at whatever vertical pitch was current when the LINE-n command is given. If that twists your mind into knots, try this: LINE-n rewinds at the vertical pitch in effect when the command is specified. The position of line no. "n" is computed anew, working from the top of the page downward. That's an important rule to remember if debugging. For a couple other posers, suppose we have top margin (TM) of 5, and from somewhere far down on the page we tell PRINT to rewind to line 4. Where does it go? Answer: It will go to line 6 because it cannot back into the margin. So it goes as far back as possible, and line 6 is the next line after the top margin. Ok. Now we know the rewind command, "LINE-n", can never go into the top margin, so we're ready for the next lesson. Suppose we have a TM 6, and a 6-line header (HEAD 6). That header will completely fill the margin. Naturally, as we have just seen, we cannot rewind to print within this header, since the header is in the margin, right? Right! (Fooled ya!) But, yes, it's possible to print within the header if we reduce or eliminate the top margin! If we say TM 0, and HEAD 6, the header will still be 6 lines — but now we can rewind into it at will, since it overflows the top margin. It's the margin itself that's forbidden territory. Much more could be said about all this, but this is a long article as it is.

Another thing you must know is that the "LINE-n" command is usually not executed precisely at the location where you have it embedded in your text line. If you place it after a RETURN, that's all right. But when PRINT is justifying text and sees

Back to the Heathkit Index

Page Four Page Six