Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!uc!noc.MR.NET!msi.umn.edu!umeecs!umich!yale!cs.utexas.edu!sun-barr!newstop!texsun!csccat!larry
From: larry@csccat.cs.com (Larry Spence)
Newsgroups: comp.lang.postscript
Subject: Re: PostScript Level 2 Q & A
Message-ID: <3972@csccat.cs.com>
Date: 26 Oct 90 01:23:15 GMT
References: <7646@adobe.UUCP>
Reply-To: larry@csccat.UUCP (Larry Spence)
Organization: Computer Support Corporation. Dallas,Texas
Lines: 113

In article <7646@adobe.UUCP> orthlieb@adobe.COM (Carl Orthlieb) writes:
>
>+ User paths are self-contained procedures that consists entirely 
>of path construction operators and their coordinate operands. User 
>path operators perform path construction and painting as a single 
>operation; this is both convenient and efficient. There is a user 
>path cache to optimize interpretation of user paths that are invoked 
>repeatedly. => Performance, convenience.

Let's say I'm an MS-Windows graphics app (I'm not, but I know one or two %),
and that I'm printing through the new Adobe PS driver.  How can the driver
know whether I want something done as a user path?  Seems like only the
app would know "this object is going to be rendered a _whole_lot_, and
maybe we should just rasterize it once."  How will I be able to take 
advantage of user paths without doing my own driver (as I essentially
have to now)?

>+ A form is a self-contained description of any arbitrary graphics, 
>text, and sampled images that are to be painted multiple timesQon 
>each of several pages or several times at different locations on a 
>single page.

Can you give us some idea of when it will be appropriate to use a user
path vs. a "form"?  

>+ The new pattern color space provides the ability to establish a 
>pattern as the current color. Subsequent use of operators such as 
>fill, stroke, and show apply "paint" that is produced by replicating 
>(or tiling) a small graphical figure called a pattern cell at fixed 
>intervals in x and  y to cover the areas to be painted. The 
>appearance of a pattern cell is defined by a PostScript language 
>procedure, which can include any arbitrary graphics, text, and 
>sampled images.

Again, this isn't functionality that's directly supported in common GUIs
(e.g., Windows, Mac), so am I stuck with doing "escape calls" and sending
PS code to the printer myself?  I like the idea of having this amount of
functionality in PS, but getting at it looks a little messy.

>+ Applications developers will be able to write a single driver for 
>a variety of different PostScript printers. The same code can be 
>used to address printer specific features whether the features exist 
>in the printer or not. If the feature is not in the printer, the 
>application can decide how to best respond to the lack of the 
>feature. 

Sounds like the printer-specific code moves up out of the driver and into
the app. %( %<

>Allocation of memory and other resources for 
>specific purposes is under software control. For example, there are 
>parameters controlling the maximum amount of memory to be used for 
>VM, font cache, pattern cache, and halftone screens. => Flexibility.

Can I specify a higher limitcheck for filling and stroking, i.e., more
points in a path (please, please %)?

>Dictionaries
>------------
>
>+ Many Level 2 operators expect a dictionary operand that contains 
>key-value pairs specifying parameters to the operator. Language 
>features controlled in this way include halftones, images, forms, 
>patterns, and device setup. This organization allows for optional 
>parameters and future extensibility. For convenience in using such 
>operators, the PostScript language syntax includes new tokens, << and 
>>>, to construct a dictionary containing the bracketed key-value 
>pairs. => Convenience, extensibility.

This sounds like a major change from a language-design point of view.

>The feedback we have received so far confirms that we are 
>doing the right thing on all fronts.

Let's not get cocky, now. %)

>*** Are Level 1 and Level 2 implementations compatible?
>
>All existing programs that run on today's PostScript printers will 
>run on a Level 2 device. That is, PostScript Level 2 is upward 
>compatible with the existing installed base of printers and print 
>drivers. However, it is not 100 % backward compatible. A file 
>written specifically to take advantage of some Level 2 features will 
>not run on a Level 1 printer because some functionality cannot be 
>emulated. Most Level 2 features can be emulated on a Level 1 printer 
>and an intelligent driver can conditionally use Level 2 features 
>when available, and fall back on Level 1 operators when not. The new 
>red book will include an appendix that will help ISVs deal 
>specifically with compatibility issues.

I dunno.  This is my major gripe.  I thought that the neatest thing about
PS was that it was extensible; that new features could be emulated in
terms of old operators.  First you say that the app will have to decide
what to do about L2 operators on an L1 device, but then you say that "an
intelligent driver" will provide this emulation.  I would really like to
get some clarification on this, it's a potential sore spot.

>+ Adobe is developing drivers for the Macintosh, Windows 3.0, and 
>OS/2 Presentation Manager environments. These drivers will take full 
>advantage of the features and performance enhancements in PostScript 
>Level 2 printers as well as existing PostScript printers. 

Again, the question is "how will the _app_ take advantage of these goodies?"

>+ Adobe is developing new controllers based on the latest RISC 
>technology which are up to 22 times faster than current controllers. 
                      ^^^^^^^^^^^^^^^^^^^^^
Yum! [eyes glaze over] %)

-- 
Larry Spence
larry@csccat.cs.com
...{uunet,texsun,cs.utexas.edu,decwrl}!csccat!larry