Crawly Crypt Collection 1/crawlyvol1.bin/utility/dtp/fontkill/dctjun92.doc

Text File | 1992-06-04 | 37KB | 695 lines

Beyond the Dot Matrix: Avoiding Rick's Sneers
Myths and Mysteries
(C) 1992 David C. Troy

Caption for (.GEM) Graph: Increased printer resolution creates a
parabolic growth curve for the amount of data sent to a printer to
obtain full-resolution graphics. Clearly, sending 75MB to an
Imagesetter at 2540dpi would be unacceptably slow.

Caption for .IMG File: Our "shaded box and a couple of words"
example. At 8.5" x 11", at 300dpi, this graphic could be over one
megabyte and would take a good while to send to a high-resolution
printer.

Please put the following table, in a box, with this article.

Amount of Data Required
for Some Common Printers to Produce
an 8.5 x 11 page at their Maximum Resolution:

     Printer             Resolution     Data Represented (bytes)
     Epson 9 Pin (Old)   144 dpi        242352
     Epson 9 Pin (New)   240 x 216dpi   605880
     Epson 24 Pin        360 x 180dpi   757350
     Atari Laser         300dpi         1051875
     HP Deskjet          300dpi         1051875 (561000 with PCL)
     QMS-MR815           600dpi         4207500
     Lino Imagesetter    1270dpi        18850769
     Lino Imagesetter    2540dpi        75403075
     POSTSCRIPT          Any            Usually (Ideally) 13-400K

A Hearty Hello
     I have a surprise for you! It isn't Jello! No, it's your
favorite thing! What do you think it is? Ice cream? Escargot? A
thesis on the viability of prosthetic limbs? Nope! We're going to
talk about Atari desktop publishing -- BEYOND THE DOT MATRIX,
past the LASER, to where only a few, really nutty people actually
get in the Atari world: the IMAGESETTER zone.

     We're going to talk about the theory behind computer
printing. We're going to talk about different ways we print when
using our two favorite Atari DTP packages, Calamus and PageStream.
And then we're going to talk about why using an IMAGESETTER with
either program is a new kind of adventure -- and how it blows the
bottom right out of the standard printing "envelope." And then
we'll talk about some problems specific to Pagestream IMAGESETTER
usage. It'll be fun.

Ways Printers Think About Data
     Imagine: it's the stone age. It's 1980. You have a bitmapped,
black and white picture file on your Atari 800 you want to print
out on your Epson MX-80. How do you do it? You send it to your
faithful printer, one dot at a time. You take care to give it the
message, "Hey this is gonna be a bunch of dots," before you start,
and you're careful to line the dots up in rows the printer can
understand.

     One painful line at a time, your picture was trudged out.
This might have taken ten minutes. Your computer was tied up
during that whole time, "waiting" for your printer to be free.

     This, my friends, was the roots of Desktop Publishing. A sort
of "Neanderthal Man" DTP system: printing a controlled, graphical
array of dots. And you were there.

     Back then you were only talking about printing out a low-
resolution picture. Your printer's resolution hovered in the range
of 144dpi (on a good day, for nice printers.) If you scaled your
picture to cover an entire 8.5" x 11" page, you were talking about
sending your printer a mere 237K of computed data. The fact of the
matter is that your parallel interface can send that very quickly,
in under a minute to be sure.

     But we all know that dot-matrix printers can only take one
line's worth of data at a time. And we all know that your Atari
800 didn't have 237K worth of RAM to hold the computed graphics
data. So it didn't matter how fast the computer could send the
data! We were stuck waiting for the printer to print, line by
line, and we had to wait for the computer to figure the image
data, one line at a time. Some of us got 64K printer buffers,
where large hunks of our 237K page could wait while data were
processed by the printer, but that only cut 25% off the time the
computer would be tied up for a page of graphics. (The computer
won't be free until the last 64K chunk is in the buffer, and there
won't be 64K free in the buffer until the other 173K is printed,
and that takes time.)

     It didn't matter, then, that in relative terms, 237K was a
lot of data (a 1050 won't hold 237K under any circumstances) to be
sending around. We were bound by the speed of our printer. We
could have sent it two megs worth of data and it wouldn't change
the speed at which the printer prints one line.

     Nine-pin printers gained resolution by the mid-eighties. The
best ones available now can produce images at up to 240
(horizontal) by 216 (vertical) dots-per-inch.

     If we printed our scaled picture from our 800 to this sort of
printer at its best resolution, we'd be talking about sending it
roughly twice as much data (240 x 216 dpi up from 144 x 144 dpi).
In fact, we'd have about 600K of print data.

     Twenty-four pin dot matrix printers brought resolutions up to
360 (horizontally) by 180 (vertically). This brings our high-rez
8.5" x 11" bitmapped print data up to about 700K. It's not
dramatically more, but it is more data. But another advancement
was made with twenty-four pin printers: they print lines of
graphics faster. So even though we're dealing with another 10% of
data, our print time for an 8.5" x 11" page of graphics might be
roughly the same from a nine and twenty-four pin printer.

     Enter laser printers. They show up at 300 dpi (horizontally
and vertically), and suddenly our 8.5" x 11" page jumps up to 1MB
worth of print data. Bells should be going off. It takes a few
minutes, indeed, to send 1MB through parallel or serial
interfaces.

     What if our page was nothing more than a big shaded
rectangle, with a couple of words written inside of it? Through
conventional methods, the computer would compute each line in a
temporary buffer, send it to the printer, and it would print the
rectangle -- one line at a time. But wait! Laser printers can't do
that! They have to print one whole page at once! So we have to
send our laser printer the entire megabyte worth of dot-matrix
data. And the laser printer has to have a megabyte of RAM online,
to store this data, so that its laser controller can scan it onto
its drum in one swell foop. And we've already said that it would
take several minutes to send over this one megabyte worth of data!
All this to print a dumb shaded box with a couple of words on
it? And your printer probably has more RAM now than your computer?
Time to do a reality check.

     It would be much simpler if, rather than our laser printer
being simply a dot repository with toner, it could do a little
thinking on its own. If we could say to the printer, "Hey,
printer, give me a box about so big, shaded, with some words
written on it in this here font." Asking the printer to do this
might only take a few lines of "program code." We'll come back to
this.

     There is another way to make things simpler, and I've talked
before about how the Atari laser printers work. They "share"
memory with the computer, and the computer does all the thinking
for the printer. It sets up the page in its RAM, and the high-
speed DMA interface allows the printer to image on its drum
directly from the computer's RAM. This is smart. The DMA interface
will let us transfer that megabyte of data in a couple of seconds,
as where a parallel or serial interface might take several
minutes. We also don't have to give the printer any brains or any
memory. It's a very sexy, simple system.

     Hewlett-Packard invented what they call PCL, which stands for
something ivory-towerish like Printer Control Language. They use
it for their HP Laserjet II, III, and Deskjet printers. Many other
printers use it too. It makes an attempt to give the printer some
brains of its own, as well as some memory.

     With PCL, we can reduce the size of our 300dpi 8.5" x 11"
page to around 500K from 1MB. That's a significant reduction:
fully one half the size! But remember, that's just compressing our
data. When the 500K gets to the printer, the printer still has to
have significant brains, and a full 1MB of memory, to decode our
500K and store the 1MB  matrix. (This isn't true for the Deskjet;
it's sent the 500K of "compressed" PCL bitmap information one-line
at a time, just like a 24-pin dot matrix printer.) This is a
significant step towards being able to say, "Hey printer, give me
a shaded box and some words," but why on earth would it take 500K?
Because it isn't really saying that. It's saying, "Hey, printer,
here's some nasty muck and when you decipher it you'll find it'll
take a meg of memory." That's not real descriptive, and it's
totally resolution dependent. If you wanted to print out at
150dpi, your data might shrink to 200K. That's still too much data
and time to waste for a dumb shaded box and a couple of words!

     What do we do when we want to print out at higher resolutions
and we don't want to have to tell our application what printer and
resolution we're printing at? What do we do when 300dpi isn't good
enough, and we want to go at a full 1270 or 2540 dpi? And what do
we do about laser printers that are coming out now, operating at
600 dpi? We invent PostScript.

     PostScript was invented by the folks at Adobe Systems a few
years ago to solve printer problems. It's a language. It's an
"object oriented" language. It works a lot like reverse polish
notation. You give it a "thing" to work with, and then you define
what you want PostScript to do with it. If our "thing" was a box,
we'd give PostScript a little program that says how to make a box
(go 50 right, 50 down, 50 left, and 50 up, and trace it with a 1
point brushstroke.) Then we'd tell it where to put the box.

     In a test I did, using our "shaded box" and a "couple of
words" example, the same file that took 700K worth of dots on our
24-pin printer only took 13K in Postscript. And about 11K of that
is PageStream-induced administrative overhead. Gee. 13K. That
might take a half-second to send to my printer through a parallel
or serial interface!

     If you look at the graph I made, you'll see the parabolic
growth curve that's associated with increasing printer resolution.
(This makes sense: you're talking about a fixed number of square
inches on an 8.5 x 11 page (93.5 in2, a constant) multiplied by an
x-squared sort of curve. It follows that you'd have a parabola.)
But just because it makes sense doesn't mean that it's very
convenient. Sending your 9-pin printer 237K worth of dots is
bearable but slow. Sending your 300dpi laser printer a meg worth
of dots is very, very slow. Sending an imagesetter (at 1270dpi)
18MB worth of dots is simply unbearable, and at 2540dpi, 75 megs
worth of data is excrutiatingly painful. You can see why something
like PostScript needed to exist.

     The same 13K PostScript program that we send to my 300dpi
PostScript laser can be sent to any other PostScript compatible
device. And because PostScript is "object" and "outline" oriented,
each device will print our program at the highest resolution
possible. So when we send our "shaded box and a couple of words"
program to my 300dpi laser, we get an image that's 300dpi. When we
send it to Rick Flashman's (up at Gribnif) 600dpi QMS super-hyper-
digital laser, it comes out at a full 600dpi. When I send it to
Rick Speaks' Linotronic Imagesetter, down in Annapolis, and ask
him to print it out at 1270 or 2540 dpi, respectively, it comes
out at the full resolution. And since the program is only 13K
long, it only takes a couple of seconds to send to any one of
these swell printers.

     So, do you concede the importance of something like
PostScript? It removes resolution dependence from the data that is
sent to any printer. With PostScript, we're no longer confined to
the 237K-75MB growth curve associated with increased resolution. A
page is a page is a page. It's fair to say that a typical, fairly
complex PostScript page (8.5 x 11) is 200K (although you can find
ways to make them much bigger). 200K for a whole 2540dpi page is
nothing compared to 75MB.

     Remember that quantity of data sent to printer is almost the
only determinant of print time. Remember that at 144dpi, we're
looking at 237K. 300dpi runs 1MB (500K with PCL), 2540dpi produces
75MB, and we get 13K with PostScript. Which do you think would be
fastest and easier to adopt as an international standard?

Disadvantages of PostScript
     The primary drawback to PostScript is its price. Because
we're giving the printer brains (my QMS-PS 810 Turbo has a 20MHz
68020, 4MB of RAM, and its own 20MB SCSI hard drive), it's simply
going to cost money. I got my printer cheap at about $2000. A
printer with that kind of feature list would usually run around
$3000. Cheaper PostScript printers exist, but they are usually
slower and don't have the SCSI port for hard disk connection.
(We'll talk about why this is important soon.)

     Since Imagesetters cost around $40,000 to begin with, having
a PostScript interpreting on-board computer is not only a good
idea (so as to avoid sending it 75MB of data through a parallel
port), but it's little extra cost to add. That is, the expensive
part isn't the PostScript; it's the printer itself.


Other PostScript Considerations

     UltraScript and now CompoScript (and the PD GhostScript) are
PostScript interpreters that run on the ST. They read in a
PostScript program and then convert that into a bitmap that your
printer can understand -- be it a dot-matrix, HP, or Atari laser.
But these programs merely provide compatibility with the
PostScript standard (and turn standard home printers into viable
proofing machines for work which is to be Imageset), they do not
provide any speed increase; you're still bound to the standard
resolution-print data parabolic curve. You're looking at 600K of
data to transfer for a decent 9-pin, 700K for a 24-pin, 500K for a
PCL laser/DeskJet, and 1MB (at DMA speeds) for the Atari laser.
And if you have an 8MHz ST, you can bet your bottom dollar that it
will be slower at interpreting PostScript code than my 20MHz 68020
PostScript laser. Even a TT (a 32MHz 68030) running a PostScript
interpreter could very well be slower than a fast PostScript
printer, because the printers have the original PostScript code
built-in and optimized on a set of chips, and that hardware is
specifically designed for running the Adobe PostScript code. Your
TT or ST isn't.

     Traditional PostScript is, quite honestly, a programming
language -- plain and simple. Here's an example of a friendly
PostScript program.

/Str
(We all LOVE Current Notes!)
def
/Helvetica findfont
20 scalefont
setfont
216 216 moveto
Str show
showpage

     If we examine this, line-by-line, we see that the language
works like I said it did; it's object oriented. In the first line,
we're telling it, "Hey, consider the label Str for a second."

     In the second line, we say, "And consider a string that says
'We all LOVE Current Notes!'" And in the third line, the "def"
means, "We're gonna call that string Str."

     Then we say, "Hey, look up the font Helvetica in your 'font
dictionary' -- I'm sure you have it." We then tell it to "scale"
the font to a 20 point size, and that we want to "use" that font.
We then instruct it, "three inches three inches moveto," (216
points is three inches) which will bring its "current position
pointer" three inches from the left of the page and three inches
from the bottom. Then we say, "Hey, remember that string called
Str? Show it now at the current position." And then we say, "Hey,
you know how we're talkin' about a page here? Print the page. Yes
-- on paper."

     Very simple. This program will produce identical results on
any Postscript printer, and the output will be at the highest
resolution possible on that printer.

     There is a new version of PostScript coming into wider usage
now called PostScript Level 2, and it, among other things, allows
the encoding of the simple ASCII (meaning plain text) program into
a binary, more compact format. This becomes an issue when we start
getting 300 and 400K PostScript files. By converting the long-
winded simple minded ASCII program into binary, you might reduce
the size of the file by half its original size. The only
PostScript Level 2 printers I know of are the new Apple
LaserWriter IIf/g machines, a _nice_ 600dpi laser from IBM, and
the DataProducts LZR-960. There is currently no way to take
advantage of the features of PostScript Level 2 on the Atari at
this time. So why do I mention it?

     I did say that "your average PostScript (level 1) file was
around 200K." Then I said that some PostScript files might be 300
or 400K or more. Well, in an ideal world, all PostScript files
would be 200K. When you use a Macintosh with something like
Pagemaker or Quark Express, you'd have to work pretty hard (by
including lots of graphics) to get a PostScript file that's more
than a couple of hundred K. But on an Atari, using PageStream 2.1,
it's not hard at all to get PostScript files that run well over
one and two megabytes. The crowd breathed in sharply and reared
back, aghast at the gargantuan proportions of what he had
suggested -- indeed!

     What's the deal? Why should these files be so big? The answer
is dumbness. One of the accessories (which I mentioned earlier)
which is part and parcel of a PostScript printer is its Font
Dictionary. A standard PostScript laser printer, ever since Apple
made its LaserWriter Plus, contains the "standard 35 PostScript
fonts." (They lie; it's not really 35 fonts. It's really standard,
bold, italic, and bold-italic versions of Avant Garde, Bookman,
Courier, Helvetica, Schoolbook, Palatino, Symbol, and Times. All
those versions add up to 35 fonts.) So when you turn on your
PostScript printer, it will certainly know about these fonts.

     Here's where we get to my printer's hard disk. The hard disk
stores additional fonts that can live in the printer's font
dictionary. There are programs which will download Adobe Type One
PostScript fonts to the printer. And they can live either in the
printer's RAM (which means the fonts will dissolve when I turn the
printer off), or they can live in the printer's hard disk, so that
every time I turn the printer on, the font will be ready for me.
Sure, I don't need a hard disk on my printer, but it means that I
don't have to spend ten or fifteen minutes downloading the Type
One fonts I want to use, every time I turn on my printer in the
morning.

     The reason I bought this printer with the hard disk was that
I wanted to simulate the conditions present down at Rick Speaks'
place. He's my local service bureau -- the place with the
Linotronic Imagesetter, and his company is called Stuff, Inc. But
anyway, I wanted my printer to differ in only one small way from
his: resolution. That way I could be assured that if my files
would print on my printer at 300dpi, they'd print on his at 1270
or 2540 dpi. That's why the printer has the hard disk. I wanted to
store all the same fonts on my printer's hard disk that I'd be
using on his printer's hard disk. And our printers work the same,
even Steven.

     You should know something about Rick. Apparently Rick doesn't
feel he has to work for a living. He's very standoffish. He's very
difficult to talk to. And he hates my Atari with a passion. He
hates PageStream with a passion. There was one time last summer
when I spent a whole day down at his place, poring over a scroll
of PostScript program code, trying to figure out why my tabloid-
sized Current Notes two-page ad wouldn't image properly on his
printer. It worked great on my previous PostScript laser. Suffice
it to say that I can't get him to print any jobs for me without
him making some kind of cut on PageStream. I just ignore him and
disregard him as the MacSnob that he is. But it got under my skin
and made me wonder why I couldn't get my PostScript files down to
a more manageable size.

     Not only did my files not print in my early Imagesetting
days, but when they did print, they seemed to take an awfully long
time. Rick allows four minutes for his system to send and image an
8.5 x 11 page. For some reason, some of my PageStream files seemed
to take as long as eight or ten minutes for a single page. And he
charges a penny per second for every bit of time over the allowed
four minutes. So if he charges me $5 for a standard 8.5 x 11 page
at four minutes, if it took eight minutes, he charges me $7.40.
And when you sometimes print out fifty some pages, you don't want
to pay an extra $120, and get sneered at to boot!

     It turns out that the reason PageStream takes so long to
print is that when you use Adobe Type One fonts from within
PageStream, rather than asking you, the user, what fonts are
built-in to your printer (or stored in its memory or on its hard
disk), it assumes that your printer doesn't know about Type One
fonts at all. And every time you go to print to a PostScript
printer, and every time a captured a PostScript file on disk to
take to Rick's Imagesetter, it includes ASCII copies of every
Type One font used in the document.

     A Type One PFB (outline) file might take about 30 or 40K in
its native binary format on disk, but when you convert it into an
ASCII-hex format, it can take up to 100K in your print file. And
that's a hundred thousand bytes you have to send to your printer,
every time you want to look at your page! And if you have ten Type
One fonts in a page, you're looking at sending your printer a
MEGABYTE worth of font data alone, every time you send a page. We
already said it would take several minutes to send a megabyte of
data over a parallel interface! And if your page is very complex,
with graphics or lots of text, you could be talking about sending
your printer TWO MEGS of data! And when you bring a two-megabyte
file to Rick to get printed on his Imagesetter, you're undoubtedly
going to break the four-minute-per-page barrier and accrue what he
calls RIP (raster image processor) time at the unforgiving rate of
a penny-per-second. Totally bogus, dudes!

     Bear in mind that Rick is a font pack-rat. He has a BIG hard
drive on his imagesetter that stores every Type One font Adobe has
ever made, plus some ones I haven't heard of. Doesn't it seem
totally inane for me to:

     1) Send Rick copies of fonts he already has on his printer's
        hard disk.
     2) Have to carry around one and two megabyte files that
        should only be around 200K.
     3) Get billed (at a penny per second) for the time it takes
        to send Rick these fonts that he already has.
     4) Repeatedly (in proofing) send my own laser printer copies
        of fonts that are already on its hard disk.

     Without trying too hard, I came up with a solution to the
first three complaints.

     When you peruse through a PageStream generated PostScript
program file, you'll see that every Type One font that you used in
the document is neatly and regularly wedged in the file. They
start with the header, "!%PS-AdobeFont-1.0" and end with the
command "cleartomark". So I wrote a handy little program which
will read-in the PostScript file, search for the senselessly
embedded Type One fonts, and ask the user if each font should
remain the file. Then it will write a "fixed" version of the file,
back out to the disk, which does not contain any Type One font
that you deem unnecessary.

     How you determine which fonts are "unnecessary" simply
depends on what fonts your destination printer has online. If you
know, for a fact, as I do that your service bureau has every
Adobe font, it isn't necessary for you to re-download the same
Adobe fonts. If, though, your service bureau doesn't have some
weird PD Type One font that you downloaded from a BBS, it makes
sense to bite the bullet, keep the 100K of font data in the file,
and include it. But even if you just remove two Type One fonts
from your PostScript file, you've pared the file down by 200K or
so, which ultimately could keep you in that four-minute processing
window.

     Another way to handle it, if your service bureau would like
to download the fonts you're using into their Imagesetter's memory
(or hard disk -- and you should recognize that you're breaking
copyright laws by doing this with commercial fonts), is to give
your local Rick a disk that has all the esoteric fonts you're
using for a set of pages beforehand. That way, he can download the
fonts once to his printer, and you can remove all the Type One
fonts from your PostScript program files. So then if you use
"Cheese-DisplayFace" in six of your documents, you don't have to
send the font six times. Only once, in the beginning. And he
probably won't count the font download time as "RIP" time; he'll
think it's perfectly natural that you'd need to download a few
fonts. MacPeople do that sort of thing all the time.

     Another workaround for this problem is to simply put all six
of your document pages into one document, and to print all six
pages into one PostScript file. But unfortunately, there are bugs
in PageStream that cause unpredictable things to happen when you
do this. Sometimes frames are rotated at random. Other times,
you'll find frames missing, or inexplicably overlayed on other
pages. I don't print more than two pages at a time into one file,
and I've had good (if mildly verbose) PostScript results.

Gee Dave, That's Such a Big Hassle!
Why don't you use Calamus?

     Going to an Imagesetter using Calamus is even more of a big
deal than when using PageStream (if you can believe that!) You
see, Calamus doesn't speak PostScript, really. That's one of the
reasons it's so darn fast when using an Atari laser. By using
proprietary font and graphics encoding, it can compute the 1MB
worth of bitmapped page data required for the Atari laser on an
8MHz 68000 in just a few seconds. But recall that a bitmap of an
8.5" x 11" page on an Imagesetter at 2540dpi is 75MB of bitmapped
printer data. You don't want to send that to an Imagesetter over a
Centronics-type parallel interface!

     So what the swell folks with DMC in Germany did was make a
raster-image-processor hardware and software combination that
allows an Atari ST running Calamus to send the Imagesetter that
75MB of data over the high-speed DMA port, so it gets sent
basically as fast as the computer can create it (real fast.) This
is a great system. It's the same idea as the new Goldleaf
Imagespeeder system (which uses a TT as a printer interface). But
the problem here is that unless you own an Imagesetter, (which
will set you back a good 40,000 bucks), you have to find somebody
who has an Imagesetter who has an ST/TT attached to it, who has
the Calamus hardware and software interface, you're not going to
be able to get Imageset output without going through the mail.
Good Luck! That sounds reai fun.

     I have heard of only a few places in the entire United States
that have such a setup. None are near me in Annapolis, Maryland.
Not only that, but quite frankly, I Like Adobe Fonts. There are
lots of them! They're pretty. Calamus doesn't use them. I don't
want to give them up!

Other Issues

     I mentioned that I cured all but my fourth complaint in my
list of PostScript woes. If you recall, the fourth complaint was
that I had to repeatedly send the same fonts when I was proofing
my documents from within PageStream. (Alternatively, I could print
the files to disk and then run my program on them to remove the
fonts and then send them to my printer, but it hardly seems worth
the hassle; I'm not being billed for the print time.) Ideally, I
wouldn't have to send any Type One fonts, ever, to my printer from
PageStream. It would be swell if I could just tell PageStream
"Hey, don't send that font." Or maybe PageStream should use a file
that indicates which fonts should be downloaded.

     The way it's supposed to work (I looked it up in a PostScript
programming book) is that the printer interface should be
bidirectional. The application (PageStream) should be able to ask
the printer, at the start of a given work session, "Hey, printer,
what fonts do you have online?" The printer would tell PageStream,
and then PageStream would know not to send any fonts that the
printer already knew about. But unfortunately, the parallel
printer port, which has become the defacto printer communications
standard on the ST, isn't bidirectional. And even if you go
through the serial port, which certainly works, PageStream still
does not query the printer for on-line font information. So the
effect of using the serial (RS232) port is the same as using the
faster parallel port: the blind transmission of unnecessary fonts.
Ours is not to reason why.

     I hope and pray nightly that a press release I read last year
will come true. I heard that SoftLogik had an Appletalk printer
driver in the works. Since almost every PostScript laser speaks
Appletalk, and because the TT, Mega STE (and new Falcon) are
capable of speaking Appletalk, it is the ideal interface for the
next generation. Not only is Appletalk faster than any other
currently available Atari print protocol, (along the lines of a
few hundred K per second), it would allow the kind of controlled,
interactive, reliable communication necessary for PageStream to
query its printer about font information. It would also open up
PageStream to network printing.

     Please, Deron, save us all. Make smart font-downloading a
part of the new Appletalk system! Support PostScript Level 2. Fix
the PostScript driver to print more than two pages at a time
correctly. These are just suggestions; don't let us get you down.
PageStream 2.1 is an excellent program that I still love to use,
even after being exposed to the somewhat less quirky mainstream
alternatives.

Other Type-One Gripes

     Now that I wrote my handy little font-removal program, Rick's
bitching and moaning about PageStream less. I brought almost all
my two-page PostScript files to between 100 and 400K. I only
incurred a little bit of rip-time on one page, which had some
complicated graphics. I'm happy, but recognize the absurdity of
this new and improved scenario:

     Now, when I create a PostScript file, I have to run it
     through another program to surgically remove half of it.

     Why not do this the easy way and get PageStream to print
     a PostScript file that's half as big?

     That's my plea to you, SoftLogik. Make this reality. End my
hell. I'll be releasing my program into the public domain in a few
days. It's a stupid, hare-brained little program whose basic
function could just as easily be accomplished with a text editor -
- it just helps speed things up a bit. I let you use the mouse
with alert boxes to choose which fonts to "keep" in your file. I
will try to talk Joe into putting the program onto an upcoming PD disk.
And I hope that my program will help some of you lower your rip-
time bills.

     Now, of course, it's perfectly possible that I've just gone
about all this the wrong way. Maybe someone else has a better idea
on how to solve the "too many fonts" in the PostScript file
problem. There are manipulations and negotiations that can be made
using ".PSF" files, and the "FONTEQUIV" file which will cause
specified Type-One fonts not to be downloaded at print time. But
they almost always involve coming up with entire families of hard-
to make "decoy" font files which will "fake-out" PageStream. I
don't think that anyone has a solution which is as simple as it
should be, which is to be able to say, "Hey PageStream, just don't
download these fonts."

     There's the issue of Type One font screen redraw speed.
Because PageStream does not cache Type One fonts, and because of
some other dumb things in its code, Type One fonts take entirely
too long to draw on-screen, especially at small point sizes. A
page worth of 10 point Type One text might very well take two
minutes to draw on-screen, even on a TT030 with a 19" monitor.
(The comparable CompuGraphic or bitmap font takes only a few
seconds.)

     The solution that SoftLogik proposes is to use what's called
an "ABF" file, or Adobe Bitmap Font file. They slightly speed up
Type One redraws, but it's still nothing spectacular. ABF's are
hard to find. There are some PC programs which will create ABF's
from the PFB (outline) files. Don Turnock's new version of
BitMaker will also create ABF files, but recognize that Type One
fonts are an incredibly diverse family and some fonts, which may
not be drawn in an entirely orthodox fashion, may give BitMaker
(or similar programs) some trouble.

     Another way out might be for SoftLogik to begin caching Type
One fonts, to create bitmaps in memory when a font is first used,
and to give the user the option of downloading the font. This way,
all Type One problems are addressed.

     1) Small point-size text is cached and drawn using the
        computed bitmap font that's in memory.
     2) Large point-size text is created from the cached Type-One
        outline.
     3) Type One fonts would not, then, be unnecessarily
        downloaded to your printer or your PostScript file.
        (Interactive querying of the printer could make this even
         smoother.)

     PageStream has some other dumb "features" which slow down
screen redraws. The FontList file is sorted after every keystroke.
The FontEquiv file is consulted after every keystroke. That's
dumb. That kind of thing eats processor time. I understand Deron
fixed that in PageStream 2.2 for the Amiga. Maybe 2.2 will be out
soon for the ST/TT.

     Perhaps Deron could find time to support PostScript Level 2,
also. This would mean that even if you did have a large amount of
PostScript data to download, binary compression would cut it down
to a more manageable size. And Appletalk transmission would make
that even faster.

     Only when all of these changes are implemented will Type-One
font usage become as easy, fun, and fast as it could be under
PageStream. That's not to say it's unusable. It could just be so
much nicer.

Contact Me!

     If you have any great experiences or suggestions for the
general world (or me) regarding Imagesetter usage, PageStream,
Calamus, or anything else, please contact me. I would love to hear
from anyone who might shed some light, and I promise to reprint
constructive comments here.

     For anyone who's totally lost as to why anyone would want
Imagesetter output, and thinks 300dpi is just fine, they could be
right. But take a look at this month's Toad Computers ad
(centerfold). I go to a fair amount of trouble to show off the
beauty of Imageset output in those ads, and for one thing, it lets
me make those nice 11 x 17 pages. I think you'll find it's worth
your time for some work.

     So here we are. We're making the trek. It's a long and
punishing road, filled with double standards and inconsistencies.
But we're making it work. We're getting output. I don't want to
commiserate, but rather clear the air and start a forum where we
can iron out some of these very complex and confusing printing
issues. If you have anything to say about this topic, please
contact me.

Phone: [phone]
  FAX: [phone]FAX
 MAIL: David Troy, 556 Baltimore Annapolis Blvd.,
       Severna Park, MD 21146
GENIE: Toad-Serv.
CompuServe: 72470,1605
Internet: [e-mail]