 SWIFT GIFT

(The Evolution of A Utility Program ...and a Surprise For the 
ADAM Community)
                                           by Pat Herrington
=================================================================
Christmas comes a bit early this year for graphics lovers...  and 
boy, do WE have a surprise for YOU!  Would you believe a never-
before-released font utility by Sol Swift? You read that right!  
And I just can't wait for the holidays...  I've waited LONG 
ENOUGH!
 
I bought FontPOWER (copyright Digital Express) when it was first 
released, and I have been fascinated with fonts ever since.  The 
first font I ever designed was called "Unica.fnt", which I later 
sent to Sol Swift as a Public Domain contribution (it appears on 
one of his "PaintMates" disks.) It didn't take me long, however, 
to begin feeling restricted by the 8x8 pixel format.  That's why 
I designed alphanumeric files in both Sprite and Clip format for 
my very first commercial release (POWERTOOLS.) I was pleased with 
those new "fonts", for sure...  but I'm greedy.  I wanted still 
MORE font options.
 
Then, in 1989, I was talking to Tony Patterson on the telephone, 
and he suggested that it would be interesting to design a font 
set that would be the same width as a regular font, but twice as 
tall...  and easily accessed from the keyboard, just like a 
regular font.  This sort of thing, he noted, could be 
accomplished by designing all the capital letters as the TOP half 
of the font, and all the lower case letters as the BOTTOM half of 
the font.  Then, you could just type in your text with the caps 
lock on, and type the same text directly below it with the caps 
lock OFF.  You would be able to come up with some really sharp-
looking letters, and they would fill a gap between fonts and 
Sprite letters.  Best of all, they'd be super easy to USE!
 
I was absolutely enthralled with the idea, and I set out at once 
to design just such a font.  I liked the results so much that I 
spent the next several years (on and off) designing similar 
fonts.  The fruit of those efforts was released as "FONTASY!  
Volume 1A:  Double Decker Fonts".
 
But this was by no means an easy task.  While FontPOWER is not 
difficult to use, it IS problematic to design a double-decker 
font using the program.  It's no easy matter to look at the 8x8 
pixel grid and imagine how the top half of the letter will line 
up with the bottom half, particularly on the fancier fonts and 
fonts in which there are crossbars right across the middle.  I 
kept thinking how nice it would be if I could line them up in a 
PowerPAINT screen and then save them as a font file.
 
Then, one day in 1990, I was talking to Sol Swift on the phone.  
I had already sent him some of my earlier double deckers, and he 
had called to ask me for permission to use them in his new 
software.  As we talked, it occurred to me that he MUST have an 
idea of how to save pictures as fonts; in fact, he had already 
done so, with the default user fonts on PowerPAINT.  So I asked 
him.
 
Now, Sol knew that I am very timid about my ability (or lack 
thereof) to figure out any BASIC program that doesn't have all 
the User-Friendly "bells and whistles" to guide me along.  So he 
offered to let me send him my picture files, and promised to 
convert them to fonts FOR me.  But this seemed like an awful lot 
of trouble, considering how many fonts I had in progress; so I 
told him that if he could write me a program, I'd manage to deal 
with it myself.  
 
So he whipped me up a short and sweet little program and mailed 
it to me.  
 
He also sent me a PowerPAINT 10k file to use as a template, 
showing just where each character needed to appear on the screen 
in order to be saved as a font file, with each character in its 
correct location.
 
I had trouble right off the bat.  The first time I tried it, I 
ended up with half my characters in the wrong position.  I don't 
remember HOW I happened to figure out what was wrong, but I 
did...  Sol had made a minor error in the placement of the 
characters on the picture file, and that small error caused 
everything AFTER it to be offset by one place.  Anyhow, I made a 
modified template which fixed the error, and everything went 
fine.  The BASIC program itself worked flawlessly.
 
 Here is the original program, in its entirety:
 
 05 REM FontGRAB by Solomon Swift circa 1990
 06 REM (lines 05&06 added by PJH)
 10 REM picture fonts to bit image fonts
 20 LOMEM :33000 :REM bload your.HRP,A29696
 30 REM bload any.fnt,A56320 
 40 REM RUN this pgm
 50 REM when done: BSAVE new.fnt,A56320,L1024
 100 FOR x=0 TO 239: pk=PEEK(116*256+16+x)
 110 POKE 221*256+x, pk:NEXT
 200 FOR x=0 TO 239: pk=PEEK(117*256+16+x)
 210 POKE 221*256+240+x, pk:NEXT
 300 FOR x=0 TO 239: pk=PEEK(118*256+16+x)
 310 POKE 221*256+480+x, pk:NEXT
 400 FOR x=0 TO 39: pk=PEEK(119*256+16+x)
 410 POKE 221*256+720+x, pk:NEXT
 
As I said, SHORT & SWEET; and it worked swell.  So WHY would I 
MESS with it?
 
Well, there are TWO reasons.  First of all, I tended to collect a 
whole bunch of picture files and then convert them all at once.  
This meant I was doing a lot of redundant typing from the 
keyboard...  I kept having to tell the program to save the file 
at the designated address.  This kind of repetetive entry puts me 
to sleep after awhile, and I end up making errors.
 
The second reason, however, is more important:  I do NOT use this 
program every day.  I might not use it for six months.  By that 
time, I have forgotten everything I learned last time I used it, 
and I have to learn how to use it all over again.  This might 
take a few minutes IF I can find my notes from last time, but if 
I have mislaid the notes, it could take an hour or so.
 
So what I wanted the program to do was print messages onscreen 
reminding me of what I needed to do.  I also wanted to automate 
it just enough to avoid typing in the same line every time I 
wanted to get a file and/or store a file.
 
So I added a bunch of lines to solve those problems.  Then I ran 
into another problem, because some of the lines I'd added called 
for "PRINT CHR$(4);".
 
If you're a novice at BASIC and don't know about CHR$(4), it is a 
very handy way to tell the computer to accept the following 
instruction just as though it were a BASIC command typed in 
immediate mode.  And, if you're a novice, I know very well that 
this explanation is not enough to help you understand it.  I have 
been wanting to write an article about it for a long time, but 
that's for another session.  Right now, the main thing I want to 
get across is that there is sometimes a problem when you use that 
instruction.  The "Control D buffer" which is used by that 
instruction has limited space; so you can easily run into trouble 
if you ask it to hold too many characters.  Guy Cousineau has 
given me a fix for that problem, but again, that's a subject for 
another article.  Meanwhile, the fix I got from Gregg Noblett was 
simply to keep the filenames REALLY SHORT.  That's a real quick 
fix, and it WORKS.
 
SO...  if I am using that line and name a file something like 
"HULLABALOO", I will get the message, "CONTROL BUFFER 
OVERFLOW"...  and the program will crash.  I'll have to start 
over.  But I can sidestep that problem by naming the file "AA" or 
something.  After I've stored all the files, I can easily go back 
and rename "AA" to whatever filename I want.
 
So, I added a line or two to remind me that I needed to use short 
filenames.
 
If you look at the REM statements, you will notice that it took 
me about two years to actually go into the program and fix it up 
according to my own needs and preferances.  (Actually, I revised 
it to a much lesser degree about three times in the intervening 
years.  For example, I fixed it to automatically load Bold.fnt, 
which I renamed BF for ease of typing, the first time around.  
But all that was so minor I am not even going to bother you with 
it.)
 
 And here's how MY version looked:
 
 5 REM PJH Feb 4,92 revision of Swift program
 10 REM picture fonts to bit image fonts
 20 LOMEM :33000:REM bload your.HRP,A29696
 25 HOME:? "GRABfont!":?:? "February 5,92":?:?
 26 ? "There MUST be a font file":? "named BF on this medium!!":?:?
 27 VTAB 12:? "KEEP FILE NAMES SHORT"
 28 ? "TO AVOID BUFFER OVERFLOW!!":?:?:?
 30 ? CHR$(4); "bload BF, a56320"
 35 ? "Insert Source & Press a Key.":?:?:GET k$
 36 HOME
 40 ? "Name of HRP file to convert?":?:?
 41 INPUT " "; h$:?:?
 50 ? CHR$(4); "bload "; h$; ",a29696"
 100 ? "HRP loaded."
 300 REM bload any.fnt,A56320
 400 REM RUN this pgm
 498 ? "one moment..."
 499 REM when done: BSAVE new.fnt,A56320,L1024
 500 FOR x=0 TO 239: pk=PEEK(116*256+16+x)
 510 POKE 221*256+x, pk:NEXT
 600 FOR x=0 TO 239: pk=PEEK(117*256+16+x)
 610 POKE 221*256+240+x, pk:NEXT
 700 FOR x=0 TO 239: pk=PEEK(118*256+16+x)
 710 POKE 221*256+480+x, pk:NEXT
 800 FOR x=0 TO 39: pk=PEEK(119*256+16+x)
 810 POKE 221*256+720+x, pk:NEXT
 899 ?:?:?
 900 ? "Name of New Font? (1-3 Chars)"
 901 ?:INPUT " "; nf$:?:?
 1050 ? "Insert Target Disk.":? "Press Any Key When Ready."
 1060 ?:?:GET k$
 1070 ?
 1100 ? CHR$(4); "bsave "; nf$; ",a56320,l1024"
 1110 ? CHR$(4); "rename "; nf$; ","; nf$; ".fnt"
 1200 ? "procedure complete.  Another?"
 1300 GET k$:IF k$="N" OR k$="n" THEN GOTO 2000
 1400 HOME:GOTO 35
 2000 ? "Program terminated.  Type NEW to resume in BASIC."
 2100 END
 
Well, Heaven knows this is not the tightest programming in the 
world.  Just for starters, there are all kinds of unnecessary REM 
statements in here.  After I had modified the program to 
automatically take care of most of the instructions in Sol's 
original REM statements, I could have done away with those.  But 
remember, this was for my OWN use only, and I didn't really feel 
comfortable eliminating Sol's messages...  I didn't know when I 
might need to refer back to them and be unable to find the 
original program; and besides, it WAS still based on HIS original 
work, after all!  I have what some consider an almost 
pathological respect for authorship.  So I left in lines such as 
300 and 400, which served no real purpose in the amended program.
 
But I was happy with it.  So it took me a couple of years to get 
around to "personalizing" the program...  so what? It OFTEN takes 
me that long to become dissatisfied enough with the status quo to 
actually do something about it.  (Not that I'm a PROCRASTINATOR, 
or anything, of course!) Anyhow, when I DID finally take the 
plunge, I was thrilled beyond belief with what I'd done.  It's 
just amazing how satisfying it is to take a "raw" program and 
customize it so that it does what YOU want it to do.  Especially 
if you are as reluctant as I am to believe in your own ability to 
"hack" a simple program!
 
At this point, the program worked just the way I wanted it to...  
EXCEPT that it was NOT a pretty piece of work.  Plain old white 
text on black background.  And it worked only from Disk Drive 
One, so that I had to keep switching disks.  I accepted these 
limitations; they weren't a real problem for me.  But in the back 
of my mind, I always thought that this would be a nice program to 
pass on to other people, if it were just a bit more User-
Friendly.
 
So...  a couple of months ago, I sent the disk to Bob Sebelist of 
The Maine ADAM Library.  When it came up on his lengthy "List Of 
Things To Do Someday", he tackled it with a vengeance.
 
I don't know what all he did to it...  in fact, as of this 
writing, I haven't even looked at his program listing.  I was 
just too excited when I received this disk back in the mail!  I 
read the doc file, but then I jumped right into playing with the 
program.  But whatever he did, he took it a whole lot further 
than I ever expected when I sent it to him.
 
In fact, he incorporated into it a number of other things he has 
discovered in the process of working on OTHER programs.
 
Not only did Bob fix the Control D Buffer Overflow Problem, and 
enable the program to access any and all drives...  but he 
completely automated the whole shebang, so that all you have to 
do is enter the names of the files you want to load and save (and 
maybe the drives, if you don't want to use the default drive 
setup.) PERIOD.
 
Plus, he made the program PRETTY...  complete with music, a boot 
screen, and a startup screen that demonstrates those other 
techniques he's been working on.
 
I think it's finally ready to share with the rest of the ADAM 
community.  
 
And I know it will be well-received by graphics enthusiasts, 
because when I sent out the Customer Response Surveys with 
FONTASY!  1A, one of the questions I asked was whether or not 
people would be interested in such a program.  The answer from my 
customers was a thundering "YES!!!!"
 
So, FONTGRAB is OUR gift to YOU.  .........  ENJOY!!!!!!  PJH 
10/23/93
 with 
FONTASY!  1A, one of th