ouij@xurilka.UUCP (exhausted jazz surfer) (08/11/90)
I have digested whatever snippets of level II information that exist. There is a decent mention in the August Byte but Adobe sends out a press kit that is rather informative. what I find ironic is the addition of a *form*. A programmer can design a form comprimised of the usual PostScript graphics, but now the bitmap is kept around and on the subsequent uses of the form, instead of rendering the postscript code, the bitmap is copied. Which means that if your print job has something in common across all the pages, PostScript only has to sweat once, the rest it copies the bitmap. This is a valuable addition since many people have run into the situation where having a forms feature would speed up printing. However, I find it ironic that , PostScript, a language for device independance, now has commands which control and imply bitmaps. (There is a similar additional feature known as a *pattern* which lets the user define a pattern tile). Patterns are even cached. However, I think that Adobe should go one step further in the next revision of PostScript. They should allow a programmer primitives to manipulate bitmaps. There has been a lot of research lately into mathematics on bitmaps which make for interesting graphics. It would provide an extra tool in the programmers toolkit in creating graphics without taking anything from the PostScript imaging model. Bill Gates, cited that this was one of the fundamental flaws with PostScript (no commands to play with bitmaps) and that a *real* standard (sarcasm mode) TrueImage would deal with such *vital* operators. This is complete rubbish in my opinion since only people who haven't been exposed to an imaging model a la PostScript still thing in terms of bitmaps (as is witnessed in this news group by the floods of requests on how to generate bitmaps from PostScript code). TrueImage and TrueType must die for it's aprroach is wrong. a sort of mass market ``hey, we can do better since we are a bigger crowd. none of that complicated PostScript stuff for us'' attitude and I think this will happen naturually. TrueType and TrueImage is still vapourware and probably will remain that way when the RED book comes out in November. However, an experimental approach as I have described would not detract from the imaging model but rather to enhance. I don't mean to start a flame fest, but am fishing for comments on this approach. Level II looks good. if there is enough interest for level II info, I can summarize to the net. what worries me is that Level II and Level I are somewhat incompatible. And I have read conflicting reports as to how compatible they will be. The next 18 months should provide to be interesting in the PostScript community dealing with drivers that only generate Level II code or not being able to get a level II printer. This is the beautiful thing about software trade, it keeps us programmers busy :-) Ouij Dada Indugu Inc. ``And love, a burnt match skating a urinal'' --Hart Crane
glenn@heaven.woodside.ca.us (Glenn Reid) (08/15/90)
In article <154@xurilka.UUCP> ouij@xurilka.UUCP (exhausted jazz surfer) writes: >Level II looks good. >if there is enough interest for level II info, >I can summarize to the net. what worries me >is that Level II and Level I are somewhat incompatible. >And I have read conflicting reports as to how >compatible they will be. I think this would be an excellent discussion. Summarize away. As for compatibility, there are (of course) things you can do in Level II that you can't do in Level I, but there's nothing in Level I that you can't do in Level II. Most of the new stuff can be emulated on an old interpreter, but you can't implement something like "undef" very easily in Level I PostScript :-) -- Glenn Reid PostScript/NeXT consultant glenn@heaven.woodside.ca.us Independent Software Developer ..{adobe,next}!heaven!glenn 415-851-1785