greid@adobe.UUCP (01/21/88)
DISPLAY POSTSCRIPT(tm) SOFTWARE TO BE AVAILABLE ON DECWINDOWS(tm) Adobe Systems and Digital Equipment Sign Contract Mountain View, California (January 12, 1988) -- Adobe Systems Incorporated and Digital Equipment Corporation have announced the integration of Display POSTSCRIPT software into Digital Equipment's DECwindows workstation architecture. Adobe Systems and Digital Equipment Corporation have signed a contract for Digital Equipment to license Adobe's Display POSTSCRIPT software. The DECwindows program is intended to provide users with network-transparent application programming interfaces for windowing, graphics and user interface services for its systems running under the VMS(tm), ULTRIX(tm) and MS-DOS(tm) operating systems. The DECwindows architecture is based on the X Window System(tm) developed at the Massachusetts Institute of Technology. Based on the same imaging model used in POSTSCRIPT(R)-equipped printers, the Display POSTSCRIPT system is a graphics software component developed by ADobe Systems. Display POSTSCRIPT software brings the same graphics imaging power to computer displays as POSTSCRIPT software brings to printers and typesetters. "Simply stated, our objective is to bring to interactive displays the same high level of functionality and portability, as well as device independence, that we have provided in electronic printing," said Dr. Charles Geschke, Executive Vice President and COO, Adobe Systems. The result of the Adobe and Digital effort will provide application developers with a programming interface to the complete range of POSTSCRIPT's powerful graphic and font capabilities for the DECwindows environment. The Display POSTSCRIPT X Windows extension will be a full implementation of the POSTSCRIPT language and will be completely compatible with the printer version. The extension will enable application developers to use a windowing system to manipulate windows and use POSTSCRIPT software to create their images within a window in a fully device-independent manner. Adobe first announced its intention to develop Display POSTSCRIPT system technology in January, 1987. As with POSTSCRIPT software for printers, Adobe will offer the Display POSTSCRIPT system on a licensing rights basis to computer and workstation manufacturers. Today's announcement is the second Display POSTSCRIPT licensing agreement disclosed publicly by Adobe Systems. In September, NeXT, Inc. announced plans to incorporate the Display POSTSCRIPT system into their workstation architecture. Digital Equipment Corporation, headquartered in Maynard, Massachusetts, is the world's leading manufacturer of networked computer systems and associated peripheral equipment, and the leader in systems integration with its networks, communications, software, and service products. Adobe Systems Incorporated was founded in December, 1982 by Dr. John Warnock and Dr. Charles Geschke. Adobe is best known as the developer of POSTSCRIPT, the page description language prominent in an increasing number of printing devices. To date, over twenty major computer, printer and typesetter manufacturers have signed POSTSCRIPT software licensing agreements with Adobe Systems. For more information, please contact Brenda Hansen, Adobe Systems Incorporated, P.O. Box 7900, Mountain View, CA 94039. (415)961-4400.
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (01/23/88)
Does this mean that if DECWindows and/or Display Postscript catch on
Sun will be forced to announce a new "merged NeWS, X, Display Postscript"
to conform to de facto standards?
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303mlandau@bbn.com (Matt Landau) (01/23/88)
In comp.windows.news, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >Does this mean that if DECWindows and/or Display Postscript catch on >Sun will be forced to announce a new "merged NeWS, X, Display Postscript" >to conform to de facto standards? Well, since Display PostScript isn't a window server, that's not really what they'd have to do. And given that Display PostScript is OUTPUT ONLY, I bet it wouldn't be that hard to replace the imaging code in NeWS with DPS without seriously changing the lightweight process stuff or the PostScript-based input and event-handling mechanisms.
malcolm@spar.UUCP (01/24/88)
In article Mike Khaw writes: >Does this mean that if DECWindows and/or Display Postscript catch on >Sun will be forced to announce a new "merged NeWS, X, Display Postscript" >to conform to de facto standards? [Perhaps this is common knowledge...but somehow I've missed it.] A better question is....how does display postscript handle the window manager functionality? A recent non technical blurb I saw (I think from DEC) said display postscript just does handles the output model and doesn't provide for input or window manager functions. It's easy to see how DEC might just stick a display Postscript interpreter into a normal X window display but how is Next Inc. going to make it work? Malcolm
benoni@ssc-vax.UUCP (Charles L Ditzel) (01/24/88)
In article <10486@jade.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > In comp.windows.news, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: > >Does this mean that if DECWindows and/or Display Postscript catch on > >Sun will be forced to announce a new "merged NeWS, X, Display Postscript" > >to conform to de facto standards? > > Well, since Display PostScript isn't a window server, that's not really > what they'd have to do. And given that Display PostScript is OUTPUT ONLY, ... why bother? I guess I would be interested in knowing what Display Postscript can do that NeWS can't. My understanding is that it is forced to live in the native window system, single-tasking, no networking... is this correct? I suppose the allure is if you use X...but wouldn't this slow down X even more than it is now? Any info would be appreciated.
lyndon@ncc.UUCP (Lyndon Nerenberg) (01/26/88)
Isn't stuff like this supposed to be in comp.newprod ???
msc@ramoth.SGI.COM (Mark Callow) (01/27/88)
In article <10486@jade.BBN.COM>, mlandau@bbn.com (Matt Landau) writes: > In comp.windows.news, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: > >Does this mean that if DECWindows and/or Display Postscript catch on > >Sun will be forced to announce a new "merged NeWS, X, Display Postscript" > >to conform to de facto standards? > > Well, since Display PostScript isn't a window server, that's not really > what they'd have to do. And given that Display PostScript is OUTPUT ONLY, > I bet it wouldn't be that hard to replace the imaging code in NeWS with > DPS without seriously changing the lightweight process stuff or the > PostScript-based input and event-handling mechanisms. The imaging code in NeWS release 1.1 is full PostScript much as Adobe would like you to believe otherwise. Only three primitives are missing: currentscreen, setscreen, and settransfer all of which have to do with half-toning which isn't terribly interesting on a screen (especially a color screen). These primitives will almost certainly be in the X11/NeWS merge. But what about extensions? The full range of extensions Abobe is planning for Display PostScript isn't clear yet. They have announced a compressed binary format which I'm sure Sun will adopt in place of the one already in NeWS 1.1. They've also announced a function call library interface to PostScript which should work just as well on NeWS as on Display PostScript. They've also indicated the areas of some other extensions. The extensions will be very small in number and I'm sure Sun will go for compatibility where it makes sense. In summary, Display PostScript does not need to be "merged" with X11/NeWS. Only a few minor changes will be needed to NeWS to make it compatible with Display PostScript. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."