`KOBOLD7bp Aa`D2|. Q@f8>J.fABa&Aa,!N NuAaJ.k`Aa`/?<&NN\Nu/?< NA\Nu0|p<АfNuP>1 <!ra6k <!Qa$k 08|`p1NqJxBx>@Nu-|Sk 8< fpNu ACSI 0 initializing ... ACSI 0 not responding ... ACSI 0 ready ...K E!O`  @`! #@%`)+-/1 3@5`79;A C@E`IKMOQ SUY]a c@e`gikmoq s@u`wy{} @` @ ` O ` O`  @`! #@%`)+-/1 3@5`79;A C@E`IKMOQ SUY]a c@e`gikmoq s@u`wy{} @` @ ` O ` FONTKILL `IKOEN `=PACPAGE `VPANTONE PGS`^GS_22 UPG`PGS_CFG `. `.. DCTJUN92DOC FQ"FONTKILLDOC FQ"'FONTKILLPRG FQ".8Beyond 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: (410) 544-6943 FAX: (410) 544-1FAX MAIL: David Troy, 556 Baltimore Annapolis Blvd., Severna Park, MD 21146 GENIE: Toad-Serv. CompuServe: 72470,1605 Internet: dtroy@jhunix.hcf.jhu.edu `Gux}g? mzqJ# A)# i| `C X]A Yb\Z y[%@ȟ`?<}N̪3۞-,Sm06vK41oO Z4%oZ$'@0l,Dw\8?PX8G@(V wX jPn` #P<,Ӭ.a8Al?P !g TYPE ONE FONT KILLER -- (C) 1992 DAVID C. TROY, TOAD COMPUTERS ------------------------------------------------------------------ WHY THIS PROGRAM EXISTS ----------------------- When using PageStream 2.1 with Type One fonts, PageStream includes copies of all utilized Type One fonts in the download file. When using a service bureau and an imagesetter, PostScript files which were "printed-to-disk" become _very_ large when they are so burdened with these Type One fonts. Many service bureaus (like mine) charge a premium for excessive time spent on their RIP (raster image processor). If you're sending a 1MB PostScript file which contains bunches of Type One fonts, you'll definitely get charged more than is necessary. The serious bummer is that you're not even spending this extra dough for any good reason, frequently; in my case, my service bureau has damn near every font I do. So when I send them these 1MB files, I'm paying $4.00 extra just to download fonts they _already_ have. This is dumb. I thought, "Gee, wouldn't it be swell if I had a little program which would remove all Type One fonts from my PostScript files?" Yes, it would be swell. This is that program. This program will give you the option of removing any Type One font stored in a PageStream generated PostScript file. If the font is one your service bureau already has, remove it. If the font is custom, or one they've never heard of, leave it in. Font Killer will also remove the trailing "control-D" (PostScript End-Of-File) from the file. Several PostScript books specifically (and pointedly) say that leaving the EOF character in a downloadable file is a bad idea. In general, 500K PostScript files will shrink to around 100K. 1MB files will go to 500K. This utility is very useful. IT WORKS and SAVES CASH. USAGE ----- Using this program is very simple. Double clicking on the program will produce a file selector box. Pick the "Pregnant PostScript File." A neat-o VDI-compatible resolution-independent status bar will show you progress in finding the fonts in the file. When all fonts are found, you'll be prompted by a series of alert boxes, each asking whether you want to keep a particular font. Simply click on "Oh Yeah" or "NOT." After you've sentenced all the fonts, you'll be asked for a "Destination Filename." The default extension is .FIX. The destination file will be written, and you will be told if the write was successful. If successful, you will be told how many fonts remain in the file. Wild. TOS 2 and ABOVE --------------- TOS, version 2 and above, supports a desktop feature where you can "drag" a data file to a program file. "Pregnant PostScript Files" can be dragged directly to Font Killer. This will bypass the "source file" file selector box. COMMAND LINE USAGE ------------------ If you use a command line and you have several files to exterminate, you can enter as many files as you like on the command line, as in the following example: c: fontkill psfile1.ps psfile2.ps psfile3.ps Font Killer will utilize all specified files. Because I am somewhat lazy, you may not use wildcards from the command line with Font Killer, so typing c: fontkill *.ps will do little more than have Font Killer use the first ".ps" file it finds. MEMORY REQUIREMENTS ------------------- Because I am somewhat lazy, you must be able to read your entire PostScript file into RAM. On my 12MB TT030, this is not a problem, and for most 2MB and 4MB users, things should be OK, too. That means that if you have a file DOGMEAT.PS at 1,523,716 bytes you must have at least 1.5MB free. Again, this shouldn't be a big deal; I find that most of my "pregnant" files are no more than 1.2MB, and I think most users creating files that large will have at least 4MB. If there are any users who would like to see this program revised to work on a machine with any RAM configuration, they should contact me. This program has its flags set to run from TT (or SST) RAM, if you happen to be using that sort of machine. If you're using a standard ST, it will run OK despite its flags. SHAREWARE STATUS ---------------- This program may be freely distributed as shareware, and must be accompanied by this documentation file, no matter where it ends up. The shareware fee is $1. If you have any use for this program at all, please send $1 to: David Troy Toad Computers 556 Baltimore Annapolis Blvd. Severna Park, MD 21146-3818 Yes, this is a token amount. But this way, I will have $1 for every person who thinks SoftLogik should re-write PageStream to handle "smart" font downloading. If I can tell SoftLogik that I raised $300 with this program, perhaps they will consider such an upgrade to PageStream. ACCOMPANYING DOCUMENTATION -------------------------- Included in this ARC is a copy of my "Myths and Mysteries" column from the June 1992 Current Notes magazine. It is a lengthy and comprehensive discussion of the "pregnant PostScript file" issue. BUG REPORTING ------------- Anyone experiencing problems using Font Killer may call me at (410) 544-6943. I may be able to offer some tech support. Anyone who's convinced they've found bugs in Font Killer is welcome to call too. I won't guarantee I'll do anything about them, but I'd be curious to hear what you guys find. ENJOY ----- Anyone who frequently uses an imagesetter and PageStream can get some good mileage out of this program. "Exterminated" PostScript files may be sent to a standard PostScript printer. Fonts it doesn't know about (ones not in RAM or on a printer's hard disk) will be substituted with Courier. But at least then you can cut these files down to size when proofing. Good luck, and may the RIP be kind to you! PLUGS ----- To subscribe to Current Notes, the hearty Atari publication for which I, Dave Small, and other computer dweebs write, contact: Current Notes, Inc. 122 N. Johnson Rd. Sterling, VA 22170 (703) 450-4761 Subscriptions are $27 for one year, $47 for two years. It's eighty-four pages, each issue. To get a copy of the most recent Toad Computers catalog (56 pages packed with swell Atari hardware and software, including ST, TT, Lynx, Eight-Bit and Portfolio stuff), contact: Toad Computers 556 Baltimore Annapolis Blvd. Severna Park, MD 21146 (410) 544-6943 In said catalog you will see (very inconspicuously) the fruits of the labor expended in Font Killer. Each page in our catalog was imageset, and Font Killer saved us money on every page. <z^,f> 㹙>6vѯ.7X ٯ&PΣYx^r`0Dp2KJ$f(By0DO6/93l?<HNA\OJg.@3l`6 - ЭЭй3l"ҍ¼.A// Bg?<JNA #b yb/(,HhNHP/9aV/96~?9hNT?<NNVHy0NHnN'PBn`0.Rn@Ab1 n m3c Hy`HyaRHy6|Hy6NO3aTHy`HyaTHybN+O 3`c 3`6?9aTN*T09c H|3c096H|73c09c H|3c096H|(3cBg?9aTN- X?<?9aTN,X?<?9aTN-DXHyc?9aTN)\09c|=@09c|=@Hn?.?.?9aTN*hO ycy+c3ccyc3dN^NuNVBBB|B. 9aZNNT29dHNjNN>//HygPN(PXN(=@Hy0nHnN'PHy0HnN'PHy0HnN'PA| `r?<Hn 96xЮ/N'O f.f~?9aTN+THy0HydBN'P09gNSygNlA6HpHydBN'~PHy0HydBN'~PHydB?<N\?9aTN*TB. 96xЮRygN29gNlA6!?< Hn 96xЮ/N'O f^|?<c 96xЮм /09gNlA6HpN(&O ?<)09gNlA6HpN!\ @B?< Hn 96xЮ/N'O fBg?9aTN-~X|.fd?9aTN+THy0HydBN'PHydB?<N\?9aTN*THy1&09gNlA6HpN'P?<( 96xЮ/N!\29gNlA6!B. .R2.Hf@Ryc09c3cHyc?<?9aTN+PB?<?9aTN-~X .R"9aZoxN^NuNVBnHy1.?<.Hya^N&\/N'PHya^HyfNX`RyaN^NuNVBn0.fHy1|HygDN'P`t`X=|`0.H =@0. =@0.H @ n0.n0.|02.RnAgD=nf0.RnAgDB0N^NuNV=|Bn?</NT-@N.Hy1HydBN'PHydB?<N\Hn?<N\Sn0.J@f`BnBn`$<2.Af<2.RnAa^ ndm?<NT|AfNXNN^?9aTN+T09gNg"N090Jg09af?9bNJTHy2HydBN'P?<\Hya^N&\R/HydBN'~PHy2*HydBN'~PHygDHydBN'~P ybgHy2HHydBN'~P`Hy2jHydBN'~PHydB?<N\`&Hy2HydBN'PHydB?<N\`&Hy2HydBN'PHydB?<N\`&Hy2HydBN'PHydB?<N\/96x?<IN\?9aTN*>T`&Hy3"HydBN'PHydB?<N\By0J0.Rnnm|090Jfr/.?<N\NN^NuNV?<N)T0<N^NuNVAd8#fAd#fA6#fAht#fAhh#fAb#fAf#b?< N)T3hta09aN^NuNV36# hh?<4N)TN^NuNV?<MN)T n0hv n 0hx n0hz n0h|09htN^NuNV#hh# hl#hp?<[N)T n0hv09htN^NuNV8H BBB<*n BG`4?<Hy3p/ N'O f ^-@<`RG/ N'XR@H gf0R@H/?<HN\#aV*n BF`$0RFH yaV!/ N'XR@HSG0f0H yaVB3h nH|=@?./. .R/NO 0. nB0 .*@(@`0<=@=@BG`HA30H|g0.f0.gBnB` `RH|"f@ nfBn`.0.f$0.f=|09hRyh@A@!`"`H|'f@ nfBn`.0.f$0.f=|09hRyh@A@!`'`0.f0.fB8=|H|f*-H|>fA-H8=|` A-H8Bn`09hRyh@A@! .8g<`RRG-g*H|gHA30H|f n8 RRG0nmrB .J@m?Bg?<FN\BgN!DTf"A4Z1| A4Z1|A4Z1G .g<0<2.g2<`2<A?/.N%\>J@m??<?<FN\?<N!DTf 0<2.g2<`2<AA4j1@ 09hR@@/?<HN\#6~><`0@A@ 02H y6~!RG0yhm y6~ 09hH y6~BL0N^NuAgbXyb !J!_ NMYybAgb"P$h/( J@NuAgbXyb !J!_ NNYybAgb"P$h/( J@NuAgbXyb !J!_ NAYybAgb"P$h/( J@Nu#gPHygPNXONuHygPNXO 9gPNu#gPHygPNXXONuHygPNXO 9gPNu#hXHyhXNXONuHyhXNXO"9hXNu#hXHyhXNXXONuHyhXNXO"9hXNu#h`Hyh`NXONuHyh`NXO$9h`Nu#h`Hyh`NXXONuHyh`NXO$9h`NuNVH n "(fJg"¼м@ LN^NuNVH nB fB`м8 LN^NuNVH n g jDh <r`V$<H@J@fBH@ @bQB @bYB @?bUBJ@kSB&<"F€JHBЂJj LN^NuNVH n "($HBJ&<BnDB Bcp`*` B c <`6<BtjABJjD LN^NuHHy3//NhPOL/WXONuHHy3//NPOL/WXONuH o#60Hy3Hy60NXNhNPO o 60L/WXONuH o#60Hy3Hy60NXNNPO o 60L/WXONuH////NPLNuH////N$PLNuH////N`PLNuH////NPLNuH////NPLNuH o#6Hy6NX//N$PLNuH o#6Hy6NX//N`PLNuH o#6Hy6NX//NPLNuH o#6Hy6NX//NPLNuH o#6(Hy6(N//N$PLNuH o#6(Hy6(N//N`PLNuH o#6(Hy6(N//NPLNuH o#6(Hy6(N//NPLNuH o0H#6 Hy6 N//N$PLNuH o0H#6 Hy6 N//N`PLNuH o0H#6 Hy6 N//NPLNuH o0H#6 Hy6 N//NPLNuNV n " n $&JjFFJjFFN^NuNVH~ n $& n "(JfJf`n*(fJf "`ZNVH.<`b fcBCD!E xzH@:HB<M8NF E6cH@`~GG~GGH@HBҁрSEg:jփՂ`2 E c&tE Ec 6HCBBHBE|.F΂Ć꫆Jk*RA҃тgRD Dcpr``xg`fSDJf"Jf`hHAJAf HA rD `0BADH@~GcH@`0z`XEJ@gREGcH@Ejpr` |.F΁†SDLHDЄJj LN^NuNVH n $& n "((fJg*fJg H@:HB<MNE1F,<.*FHÁ…HC΃ƅąxHB<:HC>܇ۄHAHB>܇ۄH@HC>܇ۄ>ڇلHDHEHF8:|HB>ڇن>؇HC>ڇنH@HB>ڇن~>(JkڅلSG <"FHD„v 歊ȀۆنGk Gc xz`xz`SGOHG؇Jj LN^NuNVH n $& n "(*fJgx(fJgt H@8HB:LME,<.*FHÁ…HC΃ƅąb fbRD1DHBHC.h~>ЇHG~` B@H@:|FH@HAHF<0BAHBHC8:ǒxjSG҃тd6BBHBHC,h ,ІHF|` B@H@:ƒ*HEHE8BEjSF҃BdHG>H@HA0,h ,ІHF|` B@H@6HC:2HAH@xDjSF҃dhrHF<x8(z <"FHG‡v 殌΀݅߅Dk Dc ~|`~|`SDLHDބJj LN^NuNV n"n 2.HbH0|f |f`$ |g `Q`bA`2Q`VA`"Q`J0|f |f`$ |g ` Q`A`3 Q` A`# QN^NuNV 94VA68䀰|l y4VX4V 0<`0<N^NuNVH`Y4V y4V PN 94VA68fA4Z*H`0- |g / N $X A4Z"Ҽ@m?.N/TL N^NuNVH*n0- |g/ N Xg0<`20- |g /-N$dXBm ?- N/Tg0<`0<L N^NuNVH*n0- |f0<`r.0- |gV0- |f0<`R0- |g?<B?- N!P?/-?- N(bP @f m@ 0<`m *Bm0<L N^Nu o/ f pJWf`g fS `pNuNV?<?.B?<BNO -@Bg?./<?<BNO -@Bg?./.?<BNO V|N^NuNVJnl3` <`H?.?./. ?<BNO -@Jm .`?<?.B?<BNO -@Jl .3` <`?<?.B?<BNO -@ nf .Ю -@ `& nf .Ю -@ `0.g <` . oH?.N%T|J@f .3` <``` Hn . /?.?<@NO Bg?./. ?<BNO J]|=@g3` <`` . NqN^NuNVH .<".ҼS/"</N/P"X/./N/. /N',X*@f <`(M)G P/N$dX 95L0N^NuNVH .<".PS/"</N/P"Xށ 95(@JfA6X (@#5#6XB6\*T -e* -f(`  -+G#5 P`( 5f/N#X*@Jf <`(M*U`L0N^NuNV0./N#XN^NuNVH .f`t .Q*@(y5` m n l`(T o l "-Ёf T (ѭ T*`* ",Ёf -Ѭ(`(#5L0N^NuNVBn`<0.@Af00f&0.@Af10.@Af1 ` Rn nmN^NuNVBn`*0.@Af00nf0.@AfBpRn nmN^NuNVH>.=|\Af"HPgXHf0(LN^NuNVHHy5/.N'PfBG`Hy5/.N'Pf><`Hy5/.N'Pf><`0. |gR0. |?/.?<=NP>J@m 0. |g&JGm??<>NXBg/.?<`j0. |gD0. |?/.?<=NP>J@m"??<>NXBg/.?<`0. |?/.?<=NP>JGl 3`0<`?. ?N$X0LN^Nu o/ fpJWf ` <gf `SNuNV/.?<HN\-@ .f-|3` .N^NuNV0./N',XN^NuNV . @"n rJWfSWfN^NuLB@ggSBAgHJ@gHANuL rWfNu op`R@SJWfFNuL2/ f0NuSAB@gVSBAgHJ@gHANuNVH*n(n >.&MNqSG0J@mf`BSG0J@l L8N^NuNVH*n (MBn ng?.N%T| fA&H. nU|`|H| f S @  . nU| A|l0fB AH-@Hn/.?.?<@NO <g 3`0<`dA&H0f =@`J/ 0./?.?<@NO -@2.¼g .3`0<` .n0.L8N^NuNV3d80.| A-HЈ-@=|` nR2.AAd8H1Rn nm/9bN-X09htN^NuNV# b3 6`36bBy6f36j36lN,~Aa#bN^NuNV3e6`By6bBy6f36lN,~N^NuNV3 a3 aBnNq nR2.RnHAgX|1f36`36bSn0.36f36lN,~N^NuNV3{6`By6bBy6f36lN,~N^NuNV#b#b .мZ#b3d6`By6b3 6f n 36lN,~096l n 035AgX#bAc#bAe<#bAa#bN^NuNV# b36`3 6bBy6f36lN,~Aa#bN^NuNV3 gX3z6`By6b36f36lN,~N^NuNV .36n .36pN^NuNV .36r .36tN^NuNV096r696tƼ n N^NuAgbXyb !JHy6`!W #bHyb" <sNBYybAgb"P$hNuNV3 gX36`By6b36f36lN,~09cN^NuNV3 gX36`By6b36f36lN,~09cN^NuNV3 gX3h6`By6b36f36lN,~09cN^NuNV3 gX36`By6b36f36lN,~09cN^NuAgbXyb !J"/0<NBYybAgb"P$hNu NVH$.f BB`&". Bvd d``bd-@-A LN^NuNVHL&gHC H@J@g@HCBCւ-C LN^.JNuNV?.?<LNXN^NuNV?.N%BTJnn0<`,?.?<>NX=@g3`0<``0<NqN^NuScanning for Type One fonts...%!PS-AdobeFont-1.00 cleartomark/FullName[1][No end found to font:|| |Disregarding font.][Dude.][1][Beginning and end found|to an unknown font.| |Will be called UNKNOWN.][Dude.]UNKNOWN.FIX*.*Choose a Destination File Name:[2][Font:||Keep it?][Oh Yeah|NOT]No[1][ Type One Font Killer v1.0 | (C) 1992 David C. Troy | Toad Computers | | Like This? Send $1!][(410)|544|6943]:\*.*Select a PostScript Input File::\[1][File: |Successfully Written. | | Fonts Remain in File.][ Wild ] Font Remains in File.][ Wild ][1][Error while writing file.|Try Again.][Bummer][1][ | File Not Written][ Good ][1][ No Type One | Fonts Found| In File][ Yeah ][3][Silly rabbit,|Trix are for kids!|You don't have enough RAM][Gee Whiz] MMARGV=@ Wi??!TD-@ !TD-@$?!TD-?.B9??3 (( (( AAAAAABBBBBB 68 CON:AUX:PRT:*      $                               Z  ,                              *$  &8XD|:<* ,        v                "  (ln( (X&>&. . 4$f.,*   ."(L~8 &&"     P`T8T A 0.a%<9h ,~ ?$b\|?z8w?Giޜ`&'B-y~oR Ń",@@C?:W?}>x{?~2YWcA*A؀ |||Fufe3>| @ @pݬcఙZ:;?`C|fy0?z2׺xp8ppp&,x8?(Oex3`d3|>>s~z¸Db` XpHH"(]?x@zOi0 B=opv z??@~>|+% ?G?ٱ-6( HYPHEN DIC (Q"?PGSTREAMNIC Q"Gx3READ ME Q"TiWhiteBlackRed )Green)Blue)Cyan )MagentaYellowGraywDark SL BlueeE0Orange BlueePurple BlueeLE1Pinke Bluee7Z7ZBrown BlueeyDr|Forest GreeneuLime Greenne$&Radical Blue&wI%Radical Yellow Lime&06YRadical Orange Fire&<Radical Party Purple&z3Radical Sky BlueGreen& Radical Deep Sky Blue}F Radical Pollutionreen-[m$Radical Pinktionreen6Royal Purple FleshenX Human Fleshn Fleshen1Qt512Ema$  \0>J)f؃(v`. n3iǹRUa2zAA3{H9 |Nuabbre/via/tionabbre/via/tionsab/sorb/entac/cept/ableac/ceptorac/cord/anceac/count/antac/know/ledgeac/ti/tudeac/tivi/tiesac/tiv/ityadapt/ableadapt/erad/min/is/terad/min/is/ter/ingaffectedal/go/rithmancho/viesan/nouncerant/acidant/eaterant/hillan/tiq/uityany/thingany/whereapart/heidapos/tro/pheapos/tro/phesapparentap/pro/priateap/proxi/matearch/an/gelarch/eryar/mi/sticeart/istaskanceask/ingas/so/cia/tionastig/ma/tismaston/ishaston/ish/mentat/mos/phereat/tri/buteat/tri/butesaudi/enceauto/maticauto/mati/callybaby/teethbal/ancebal/ancedbal/dingbar/on/essbase/linebeach/comberbeck/onbest/ialbeta/test/ingbe/tweenbe/whisk/erbe/whisk/er/edbib/li/og/raphybind/erybi/no/mialblast/offboard/erbomb/erbore/dombouncerbound/aryboy/friendbudg/etbudg/et/ingbuff/erbuff/er/ingbull/dogbull/dogsbull/ishbull/ish/nessbuzz/erby/stand/ercandle/stickcan/openercan/openerscarb/oncast/a/waycast/offcat/ioncav/ern/ouscen/tercen/ter/ingcen/tralchange/overchar/ac/terchar/ac/terschild/ishchild/ish/nesschil/drenchordalciv/i/lizeclass/ifi/edclass/ifiesclass/ifyclass/ify/ingclass/roomclem/entclimb/erclinch/ercoars/encoars/en/ingcognaccole/slawcom/a/tosecom/bat/ivecome/backco/me/diancom/men/da/torycom/mu/ni/ca/tingcom/mu/nitycomp/trollercompu/servecom/put/abil/itycon/de/scendcone/flowercon/form/antcon/form/istcon/sult/antcon/test/ablecon/test/antcon/trol/lableco/nun/drumcopy/rightcor/nerco/starco/star/ringcoun/terc/lockw/isecount/esscourt/housecourt/yardcre/scendocrest/fallencriti/cizedcross/overcrypt/analysiscrys/tal/lizecurl/i/cuecut/outcut/outsdamp/endamp/en/eddamp/en/ingdamp/estdar/lingdebt/ordec/la/ra/tionde/class/ifi/edde/class/ifiesde/class/ifyde/class/ify/ingde/cre/scendode/duct/iblede/fectde/fectsdeform/ityde/greedemo/cratdemo/craticdemon/stratedemon/stratedde/pend/ablede/pend/entde/scendde/scend/entde/scentdesk/jetdesk/topde/test/ablede/vel/opde/vel/opedde/vel/op/ingde/vel/op/mentdi/gest/ibledis/con/form/antdis/es/tab/lishdis/es/tab/lish/mentdis/form/antdis/miss/aldis/serv/icedis/serv/ic/eddis/serv/ic/ingdis/till/erydown/loaddown/loadeddown/load/ingdown/towndra/maticdra/mati/cal/lydump/lingdupli/ca/tionearth/en/wareeast/ernedit/ableegg/headegg/nogeld/estelse/whereem/ployem/ployeeeq/uableequippedequi/va/lentequi/va/lentserr/inges/tab/lishes/tab/lish/menteu/logyeuro/stileeuro/styleeve/ningevery/oneevery/thingex/ac/ti/tudeex/ist/entex/pend/ablefall/outfalse/hoodfar/thingfencerfiend/ishfiend/ish/lyfig/ureflex/ibilityfont/abilityfor/eign/erfore/short/enfore/short/en/ingfore/stallfore/stal/lingform/antform/istfound/lingframe/workfree/domgen/er/ategen/er/at/inggen/er/atorgeo/met/ricgirl/friendgold/engov/erngov/ern/ablegov/ern/mentgraphicgraph/icsgro/ceryhandle/barhang/outhang/overhap/haz/ardhap/haz/ard/lyha/rangueha/rangue/inghard/enhard/en/edhard/en/inghard/esthard/wareharp/isthaz/ard/ousheart/acheheart/ilyhence/forthherb/alhetero/sexualhogs/headhold/outhold/overhold/uphomo/sexualhori/zon/talhow/everhyphen/atehyphen/atedhyphen/a/tionillus/tra/tionillus/tra/tionsimage/set/terim/mo/bi/lizeim/pass/ableim/per/turb/ableim/prob/abil/ityim/prob/ablein/ac/ti/tudein/ap/pro/priateinch/wormin/clem/entin/con/form/antin/con/test/ablein/depen/dentin/di/gest/ibleineq/uityin/ex/ac/ti/tudein/form/antin/fringe/mentiniq/uityink/blotink/linginn/keeperin/sa/tiablein/te/riorir/re/vers/ibleissuesjeop/ard/izejeop/ard/iz/ingkey/boardkib/itzerland/ownerlaunch/erlay/outleft/istleft/overless/enletra/setlife/stylelife/styleslift/offlime/stonelino/troniclino/typeli/on/essliq/uefyliq/uidliq/ui/dateliq/ui/dat/ingliq/ui/da/tionliq/uorlive/stocklull/abylunch/eonlus/ciousmaga/zinemaga/zinesmain/springman/ageman/age/mentman/ag/ingmar/ketmar/ket/ingmar/ketsmast/headme/ringueme/ta/bo/lizemile/stonemince/meatmin/is/termin/is/trymis/under/stand/ingmo/bi/lizemod/ern/izemod/ern/iz/ingmon/i/tormono/chromemo/nop/o/lizemo/nop/o/liz/ingmorguemouse/formneedle/workneg/li/giblene/go/tia/bleneo/chromenerv/ousnerv/ous/nessnest/lingnews/let/ternews/let/tersnews/papernon/ab/sorb/entnon/con/form/istnon/de/duct/iblenone/the/lessnon/ex/ist/encenon/ex/ist/entnon/form/istnon/metalnorth/eastnorth/erlynorth/ernnurse/maidnurs/eryob/serverodd/ballsoff/beatoff/handoff/hand/edoff/hand/ed/lyoff/printoff/setoff/setsoff/shootoff/shoreoff/springorange/adeout/land/ishpage/streampage/streamspaint/brushpal/atepala/tinopamph/letpara/graphpar/tici/patingpart/nerpass/ableped/a/gogypent/houseper/cent/agepe/ri/odicper/sist/entper/turb/ablephil/an/thropicphil/os/ophypho/to/statpixel/scriptplay/billplay/thingpleb/i/sciteplumb/erpoly/gonpoly/gonspoly/no/mialpopu/larport/holepost/alpost/hastepost/hu/mouspost/scriptpre/cludepre/cludespre/de/finepre/dict/ablepre/ferpre/req/ui/sitepre/schoolpre/schoolerpre/serv/ativepre/viouspre/vious/lypriest/hoodprin/terprob/abil/ityprob/ablepro/ce/durepro/drawpro/ducepro/duc/tiv/itypro/grampro/gram/merpro/gramspro/nouncepro/nouncedprop/erpro/vidingpro/vokepro/vok/ingpsalm/istpub/li/ca/tionpub/lishpub/lish/erpub/lish/ingqua/drilleranch/errattle/snakeread/abil/ityread/ablere/corderref/er/enceregis/tra/tionre/hears/alre/li/a/bil/ityrent/alre/placere/place/mentre/placesre/plac/ingre/portre/por/terre/portsrep/re/sentrep/re/sen/ta/tiverep/re/sentedreq/ui/si/tionre/scindre/scind/ingre/searchre/search/erre/search/ingre/sizereso/lu/tionre/solv/ablere/solvere/solv/ingre/spect/ablere/startre/start/edre/start/ingre/statere/stat/edre/state/mentre/statesre/stat/ingre/storere/stor/edre/store/sre/stor/ingre/vers/iblerevo/lu/tionre/volv/erroll/a/wayround/a/boutround/tablerun/aroundsap/lingsched/ulesched/ul/ingsearch/ablesearch/ingsea/scapeself/ishself/ish/lysell/outsend/offsense/lesssense/less/lysep/ara/tionsep/ara/tionsserv/erserv/iceserv/ice/ableserv/ic/edserv/ic/ingshare/hol/dershare/hol/derssharp/ensharp/en/edsharp/en/ingshoe/stringshort/enshort/en/edshort/en/ingshy/stersib/lingside/stepside/swipeside/swip/edside/swip/ingsi/lencersmoke/stacksnake/skinso/ciablesoft/heartedsoft/heart/edlysoft/waresom/er/saultsome/thingspecialsta/bi/lizestand/ard/izestand/ard/iz/ingstand/outstar/lingstat/urester/lingstew/ard/essstew/ard/essestiff/enstiff/en/edstiff/en/ingsuit/ablesu/pe/riorsu/pe/ri/oritysurf/ertan/ta/lizetech/niquetech/niquestele/visiontem/platetest/ablethem/selvesthermo/statthrough/outtonguetorquetoss/uptrans/parenttrans/par/ent/lytrench/anttrouble/shoottrouble/shoot/ingturn/a/boutturn/overturn/tabletypo/graphictypo/graphi/calubiq/ui/tousultra/scriptun/ac/cept/ableun/adapt/ableuna/nim/ityu/nan/i/mousun/civ/i/lizedun/class/ifi/edun/class/ifiesun/con/trollableunc/tuousun/de/pend/ableun/der/stand/ableun/err/ingun/gov/ern/ableun/pre/dict/ableun/re/solv/ableun/re/solveun/re/solv/ingun/re/spect/ableun/search/ableun/search/ingun/serv/iceun/serv/ice/ableun/so/ciableup/loadedup/swingvari/typervenge/ancevict/ualvignetteevine/yardvolt/agevol/umewall/eyewaste/bas/ketwaste/landwatt/meterway/pointweak/lingwest/ern/izewest/ern/iz/ingwhat/everwhen/everwhisk/erwhisk/er/edword/per/fectwordupwors/enwors/en/edwors/en/ingyard/ageyear/lingk~gUy <@ 6`bgTy <@ 6`FgUy : y JfQ 6`"gTy : y JfP 6 MS9 Nj. NT >Sy Fj3 H F# B >09 : z2 y 6a2Nua7Z<gb<g.<g4<gP<g<g<<g(`(a4Z` a&S9A2<Ma4`aZa<Ma4/B@EB|&zB8< (K6< f|2< La.2< La$PQ Q `ffzf`6 y :gbJ(fZ|a`/B@2<Aa `@ y :g.J(f&|a,/B@2<Aa ` `fpp pppppppppppp}U}U?}U?Floppy Drive @@@@"@B@@?p??Hard DiskRA 0px ހ?5U*?(  ??|ppRAM DiskPriUU#@ffa`1??PrinterTrasujx  X{XY9X5X1X1X1X1XXXXXXXXp9?TrashFolder                 FolderProgrUUXProgramText@ ????????????????????????????TextBatch Fx?G@@P?PPPPPP`PaP;aP3PPPp@|?Batch FileTujx  X{XY9X5X1X1X1X1XXXXXXXXp9?TRASHCANACC@ ????????????????????????????TYPE10LSFNT Pp Pp Pp Pp Pp Pp Pp Pp Pp Pp P* RSC@ ????????????????????????????* DAT??????????????????????????* AC?  PGSTREAMPRG?1ppqqp q????????????????????* FNTmmp????????????????????????????PGSTREAM* mm?   ( ?p????????????????????????????* HSDmm?   ( ?p????????????????????????????* DICmmp????????????????????????????* PRTmm>>>p????????????????????????????* IMPmm>>>p????????????????????????????* EXP      8           AUTO 9UXڪUXڪUXUUXUUXUUXUUX??????????????????????* INF .TP@ ( /> < () o ( ) ?ICONEDITAPP( )* (*(( (( ) (( ( * ** (( * NIC@ $@$$A@ $  @` A$@ ~ @?????WORDPLUSPRGUT@UT TՐTՐTՐՐTՐTՐT????????????????????????????* DOC,@d k0d]PPnP????????????????????????????* LET@ @@@@@@@@@@@@@????????????????????????????* TEMĀD@ ߐ(Pߐϟϟϟϟ????????????????????????????* ORG@ ѐѐѐhѐhѐhѐhѐhѐhѐhѐhѐߐϐ????????????????????????????* BAR@ ?????????????????????????????* PIE@ wwWQwrwrUQwrwpPuRwqwpPUrwq????????????????????????????* MCA$I$@ O$PUUPUUPUUPUUPUUP????????????????????????????* FTNI$I$@ I'I$I$I$I$I$I$I$I$I$I$I$????????????????????????????* GRP@ ????????????????????????????* BOR@ *X5*X5*X5*X5????????????????????????????* HLPUT@ T"U *U Ȑ888????????????????????????????* NEOUT@ T"U*Uϐ888????????????????????????????* P?3UT@ T"U *UȐ888????????????????????????????* P?2UT@ T"U*UȐ8 8 8????????????????????????????* P?1=$D@D 00$P$P