sjs@spectral.ctt.bellcore.com (Stan Switzer) (01/03/90)
In article <1651@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: > The fact that the PostScript imaging model does not provide > a means to "read back" the current image isn't a deficiency in Adobe's > docs--it was a conscious design decision, and one (in fact) that I agree > with. Me too. At the same time, I do feel that it would be extremely nice to be able to render the same image on the page several times without the overhead of reinterpreting the PostScript. Maybe not worth the bother in a printer, but ... > One of the nice things that NeWS does is to add a few operators (like > "copyarea") that act on the page image without letting the programmer > make any assumptions about its resolution, etc. Copyarea is indispensable if you are trying to do scrolling on a display device. Curiously, while NeWS has such an operator, Display PostScript (DPS) does not. Why? Well it turns out that copyarea might not always succeed, for any number of reasons--not least of which is that a portion of the source image might be obscured by another window and have no backing store. In NeWS, the server simply propagates "damage" to the area in question and leaves it up to the program to handle it as it handles any other damage. Unfortunately, NeWS lacks DPS's ability to control the halftone phase, which means that you can't seamlessly match gray fills to a copied area. DPS, however, does not have any notion of damage, that being the business of the underlying windowing environment, and therefore can't really do anything sensible in this case. The idea in DPS is to use the facilities of the underlying windowing system to copy areas. Unfortunately, this generally means being contented with rectangular bitblits. Another alternative would be to add system-specific extensions to Display PostScript, which is evidently what the NeXT does (the seem to be able to deal with mouse input directly in PostScript), but I do not know whether they add a copyarea PostScript primitive. About the best you could do in PostScript is to have a copyarea operator return a boolean saying whether the copy could be done. If the source data were not completely available, or if this isn't a raster device, the operation would fail. For that matter, there is no compelling reason why the copyarea operator couldn't be faked even on a displaylist implementation. The copyarea displaylist item simply establishes a clip and a translation then replays the displaylist up to the location of the current "copyarea" displaylist token. Watch out though: you'll have to recursively process copyarea tokens encountered along the way. > Of course, some enterprising hacker type could quite easily write a > bit of 68000 machine code to do this and load it in with cexec... This > would be a much more "traditional hacker" approach than whining :-). Fighting fire with fire. Maybe that's why they call it flaming. Stan Switzer sjs@bellcore.com P.S. Now that I've brought it up: surely somebody using a NeXT or DecWindows would like to discuss her or his experiences using DisplayPostScript. Of particular interest is the integration of the PostScript with the various input and event mechanisms in the underlying environment. All's I got is book-learnin'.
kent@godzilla.pa.dec.com (Christopher A. Kent) (01/03/90)
DPS doesn't need to have copyarea because the window system that incorporates DPS can supply it instead. In the DECwindows implementation, you use DPS to image into an X drawable (either Pixmap or window) and use XCopyArea to do all the copying you want to. Or you can use the resulting image as an X clipmask. Or whatever suits your fancy. NeXT chose to expose their windowing operations as PostScript operators, so it looks like they're just part of DPS. Chris Kent Western Software Laboratory Digital Equipment Corporation kent@decwrl.dec.com decwrl!kent (415) 853-6639