CompuServe Thread

Paul: That is an ecapsulated postscript (EPS) file. Postscript is a page description language that is written in ascii… which is why it 'almost' looks like english 🙂 The EPS Chris uploaded is a graphic file. About a third of the way down the code (I don't have in front of me) there is a line that sometihng like zip(10009)def. If you put a zip code in that line, and import this EPS file (IMPORT/GRAPHIC), the file will print a US Post Office bar code definig the zip code, when output to a postscript device. – Whapp!ng from the North Coast Michael

Paul PostScript is a page-definition language, which some printers are capable of turning into a page image and then printing. They're mainly laser printers (since they already basically generate a full page image before committing it to paper). The language was developed by Adobe, and is a fairly universal standard for interchanging documents for printing. Indeed, it is a complete programming language, with all the things you would expect (mathematical functions, strings, subroutines, if..then..else constructus and much much more) … so much so that there is even a Mandelbrot generator program around written in PostScript!! However, it is a rather quirky (and, of course, somewhat specialised) language which is capable of redefining its own operators and is heavil stack oriented (just like FORTH). If you used PageStream to generate a PostScript output onto an IBM-format disk (using one of the several available Amiga utilities) you could take it along to a printing bureau and print it to a high quality Lino machine, or you could print it on a friend's laser printer, or you could run it through POST on your Amiga and print it to a dot-matrix printer. You'd get the same output whichever way you did it, only the quality would improve as you went to higher quality machines. You could perhaps generate an illustration or company logo in PostScript, and it would be nice to be able to include this in another document … that is where Encapsulated PostScript (or EPS) comes in (EPSF just means EPS file). It is a set of structuring conventions to identify the EPS data and also to give extra information that the application would need (such as the size of the image), and it is also a set of basic rules thta need to be adhered to in order not to mess up the rest of the page on which the logo or illustration is printed. You can import EPSFs into PStream and ProPage, but neither of them will generate an image on the screen, nor will they print EPSFs to a non-PostScript printer. [ MORE ]

[ continuation ] That's because they would need to have complete PostScript interpreters built in, and they don't. Instead, all they do is note the EPS code, and include it without modification in the final PostScript output. Mike (Whapping from the UK)

However utilities like Pixel Script, or Saxon Script, should do the trick, when it comes to printing EPS pictures. – Well Whap! Me Silly….

Michael, That EPSF file can be found in the Adobe Forum's Postscript Library. If you take the message I posted and save it without the CIS header it is the exact EPSF code. It should work fine. Look in Adobe's library though, bro;ZIPCOD.TXT I think is the file name. Chris

Michael, Since you are using Whap!, you already have the program. Simply keep it, then go into your Amigauser.KPT file and trim off all the garbage with a text editor, and then save it out as a different file. As for directions, you manually insert the Zip code into the file. Then import the file as an EPS graphic into Pagestream. You will need a Postscript printer, or a Postscript interpreter, to print it. – Well Whap! Me Silly….

I don't think I'd go that far… Adobe does state that Type 1s have a limited set of valid commands. A good Type 1 parser must be able to handle all those useful dictionary elements, too.

Gary, you are absolutely right here and it is the basis of the point I was making. The only way to support PostScript fonts is to have a PostScript interpreter. However, Type-1 fonts use a very small subset of the PostScript language and they stick to a fairly simple set of rules. In addition, each chardef is more or less self-contained, and doesn't require the generation of a state model to know exactly what is going on. Thus, it isn't that difficult to write software that works with Type 1 fonts provided that the author has a good understanding of where the limitations will be. A good example is the fill algorithm used by PostScript; a rendering program needs to understand the even-odd rule and to do the necessary analysis of the character to render it correctly. PageStream is one program which doesn't do this … ProDraw fonts also suffer the same problem. This fill problem is a very good example of this sort of thing since, 99.9% of the time, the fill rule used by PageStream (and ProDraw) actually works just fine because most characters have any central areas within a character "empty". But, some fonts appear to have their internal and external paths following in the same direction and that means that the inner area is _not_ empty (the total character fill spills into it). These fonts don't print correctly on a proper PostScript printer, but they do print correctly on PageStream and so on! This is a classic example of why programs should conform to the rules _properly_. Mike (Whapping from the UK)

SL: In defense of Mr. Mike: The purpose of software "standards" is to ensure effortless interchange of information. How can you possibly condone an alteration to a standard by simply saying, "everybody does it"? Would it be okay for me to create a paint program that outputs IFF pics with a structure named "GARY" instead of "FORM"? By your rational, it would be as long as everybody agreed to check for both "GARY" and "FORM". And then where would it end? It would end up like the Mac, with its 22 million different picture file formats. I understand why you might choose to accept non-standard information when parsing a file's information (it makes you look good, for one thing). What I don't understand is why you don't seem to see how ultimately destructive it is… Gary – Mirror Image Prod. (416) 495-7469, via WHAP!