Display PostScript: Difference between revisions

Revision as of 23:41, 24 November 2004

Latest revision as of 10:03, 14 July 2025

(108 intermediate revisions by 68 users not shown)

Line 1:

{{Short description|2D graphics engine}}

[[NeXT|NeXT Computer Inc.]] designed '''Display PostScript''' (or ''DPS'') as a display system for their series of [[Unix]]-based personal computers starting around [[1987]]. Display PostScript was developed with (or given to) Adobe, and made an official [[Adobe Systems|Adobe]] product with its own standards documents and licensing requirements.

{{Multiple issues|

{{no footnotes|date=August 2012}}

{{refimprove|date=August 2012}}

}}

As'''Display thePostScript''' name implies,(or '''DPS''') is a [[2D computer graphics|2D graphics engine]] system for computers that uses the [[PostScript]] (PS) imaging model and language to generate on-screen graphics. InPS orderwas tooriginally supportdeveloped interactivefor [[computer printing]], on-screento usewhich DPS adds a number of features intended to ease working with reasonable[[bitmap]]ped performance,displays aand fewimprove changesperformance wereof needed:some common tasks.

Early versions of PostScript display systems were developed at [[Adobe Systems]]. During development of the [[NeXT]] computers, NeXT and Adobe collaborated to produce the official DPS system, which was released in 1987. NeXT used DPS throughout its history, while versions from Adobe were popular on Unix workstations for a time during the 1980s and 1990s.

*''multiple [[execution context]]s'': unlike a printer setting where the PS interpreter had only one job at a time, DPS would be used in a number of [[window]]s at the same time, each with their own settings ([[color]]s, [[brush]] settings, [[scale]], etc.). This required a modification to the system to allow it to keep several "[[context]]s" (sets of state data) active, one for each process (window).

== Design ==

*''[[encoded name]]s'': many of the procedures and data structures in PostScript are looked up by name. In DPS these names could be replaced by small numbers, which are much faster for a computer to find.

The original PostScript was written for printing, with the model being that only one document could be printed at one time, and that the document was broken into logical sections approximating a page. For this reason, the underlying model of PS was based on a [[stack machine]] similar to the [[Forth programming language]], which reduced the complexity of the code on the printer and the amount of memory needed to store individual graphics. The system would gather up instructions until the {{code|showpage}} command was issued, at which time all the instructions received since the last {{code|showpage}} or the start of the session were performed and the memory used by those instructions could then be released.{{sfn|Adobe|1990|p=325}}

In contrast, a display engine works in a very different environment. There is no analog of a {{code|showpage}} that will eventually allow queued instructions to be performed, generally any drawing is expected to take place immediately. Moreover, whereas a PS printer could only print one document at a time, in a modern computer with multiple display [[Window (computing)|window]]s, all of the windows could be updating at the same times using different settings. This was addressed with the introduction of ''multiple execution contexts'', each of which approximated the model seen on a printer; that is, each window effectively had its own PS context and instruction stack, and each window could then produce output with different settings, like whether or not the next line should be dashed or solid.The DPS system provided library calls to create the contexts, which could be completely independent or shared.{{sfn|Adobe|1990|p=326}} Shared contexts were useful in windowing systems because they allowed all of the windows within an application, or even across multiple applications, to share settings and especially pre-defined procedures stored in the {{code|userdict}} and {{code|globaldict}}. One particularly important use of the shared {{code|globaldict}} was to store system-wide fonts.{{sfn|Adobe|1990|p=327}}

*''[[interaction]] support'': a number of procedures were defined to handle interaction, including [[hit detection]]

The font system itself also had to be modified. PS has a powerful system that produces high-quality fonts from outline descriptions including "hints" which improve quality at smaller sizes. These all rely on the output resolution being fairly high, around 300 bps or higher in most cases. For the much lower-resolution monitors, the results were not very good. DPS added a system to allow hand-drawn bitmaps to be cached in the dictionaries, which was used to provide fonts that could be [[Bit blit|bit blitted]] directly to the display.{{sfn|Adobe|1990|p=339}} After the widespread use of 32-bit color displays the need for this sort of solution has been reduced, as [[anti-aliasing]] solves many of these issues. Likewise, DPS added [[halftone]] phase support to ensure newly drawn objects had the same halftone as earlier objects,{{sfn|Adobe|1990|p=337}} but this too has been reduced in importance on modern systems.

*''halftone phase'': in order to improve scrolling performance, DPS only drew the small portion of the window that became visible, shifting the rest of the image instead of re-drawing it. However this meant that the [[halftone]]s would not line up, producing visible lines and boxes in the display of graphics. DPS included additional code to properly handle these cases. Modern full-color displays with no halftones have made this idea mostly obsolete.

PS stored objects and code within the dictionaries using string identifiers. This made finding the definition expensive as the size of the collections grew, which was a side-effect of many of these new features. DPS addressed this by adding the ability to store objects in the dictionary using integers instead of strings. This "encoded system names" concept could greatly improve performance of various tasks like finding a system font or looking up a common routine like "draw title bar". These encoded names were stored on a per-context basis.{{sfn|Adobe|1990|pp=332-333}}

*''[[incremental update]]'': in printing applications the PS code is interpreted until it gets a <code>showpage</code> at which point it is actually printed out. This is not suitable for a display situtuation where you need a large number of minor updates all the time. DPS included modes to allow semi-realtime display as the instructions were received from the user programs.

Other changes addressed the need for direct interactivity. This included the ability to perform ''incremental updates'' so that PS commands that produced output could be performed immediately.{{sfn|Adobe|1990|p=335}} There were also systems for performing [[hit detection]], so that one could see if a particular ___location hit any of the drawn objects. This was used, for instance, to test which objects in the view were being hit at the ___location of a mouse click.{{sfn|Adobe|1990|p=336}}

*''[[bitmap font]] support'': DPS added the ability to map PS fonts onto hand-drawn bitmap fonts and change from one to the other on the fly. While PS's ability to display fonts on "low rez" devices was good, "low rez" meant something on the order of 300dpi, not the 96dpi that a NeXT screen used. This required hand-built fonts for reasonable output.

*''Finally, DPS added the concept of a {{code|pswrap}}, a [[C (programming language)|C-language]] support'':function that took DPS introducedcommands in the conceptform of astrings "[[pswrap]]",and whichsent allowedthem [[developer]]sto the DPS context to wrapbe PostScriptoutput. codeThis allowed, for instance, one to intowrite a C -language function whichthat couldproduced thena berectangle calledon from anthe applicationscreen.{{sfn|Adobe|1990|p=334}}

DPS did not, however, add a windowing system. That was left to the implementation to provide, and DPS was meant to be used in conjunction with an existing windowing engine. This was often the [[X Window System]], and in this form Display PostScript was later adopted by companies such as [[International Business Machines|IBM]] and [[Silicon Graphics|SGI]] for their workstations. Often the code needed to get from an X window to a DPS context was much more complicated than the entire rest of the DPS interface.{{citation needed|date=March 2011}} This greatly limited the popularity of DPS when any alternative was available.{{citation needed|date=March 2011}}

== History ==

On[[NeXT]] in September 1987 became the first company to license Display Postscript.{{r|lach19880118}} The developers of [[NeXT]] systemwrote a completely new windowing engine was written, to take full advantage of theirNeXT's [[object -oriented]] [[operating system]]. A number of commands were added to DPS to actually create the windows and to react to events, similar to but simpler than [[NeWS]]. The single API made the writing of stuffprogramming at higher levels much easier and makingmade NeXT one of the few systems to extensively use DPS. The user-space windowing system library [[NeXTStepNeXTSTEP]] used PostScript to draw items like titlebars and scrollers. This, in turn, made extensive use of pswraps<code>pswrap</code>s, which were in turn wrapped in objects and presented to the programmer in object form.

[[Digital Equipment Corporation]] in early 1988 licensed Display PostScript for [[DECwindows]]. Adobe said that it hoped that [[IBM]] and [[Microsoft]], for [[OS/2]] [[Presentation Manager]], and [[Apple Computer]] would also use the technology.<ref name="lach19880118">{{Cite magazine |last=Lach |first=Eric |date=18 January 1988 |title=Adobe Urges Apple, IBM To use Display PostScript |url=https://books.google.com/books?id=Dz8EAAAAMBAJ&pg=PA5#v=onepage&q&f=false |access-date=2025-05-25 |magazine=[[InfoWorld]] |page=5 |volume=10 |issue=3}}</ref>

[[Apple Computer|Apple]]'s [[Mac OS X]] operating system now makes use of a similar imaging model to Display PostScript, but does not have the same level of programmability. The new system, known as [[Quartz (Macintosh)|Quartz]], is based on the [[Portable Document Format|PDF]] model in which the source of the image is not the PostScript code itself, but the result of interpreting that code. It keeps the basic graphics primitives, font handling and measurements, and in many cases looks and feels like DPS. It is not entirely clear why this switch happened, but speculation suggests that Adobe was asking for a high [[licensing fee]].

In November 1993 Sun Microsystems shipped [[OpenWindows]] 3.3, which dropped the support for [[NeWS]] and its non-standard extensions to PostScript, replacing it with DPS.

==See also==

*[[NeWS]]

*[http://www.nongnu.org/backbone/ GNU/BackBone]

*[[Portable Document Format]]

*[[DisplayPDF]]

*[[QuickDraw]]

== Modern derivatives ==

==External links==

*[http://c2.com/cgi/wiki?DisplayPostscript Description at C2 Wiki]

After acquiring NeXT, Apple's [[macOS|Mac OS X]] operating system uses a central window server (created entirely by Apple) that caches window graphics as bitmaps, instead of storing and executing PostScript code.{{Citation needed|date=February 2018}} A graphics library called [[Quartz 2D]] provides PostScript-style imaging using the PDF rendering model (a subset, plus tweaks, of the PostScript model), but this is used by application frameworks—there is no PostScript present in the Mac OS X window server. Apple chose to use this model for a variety of reasons, including the avoidance of licensing fees for DPS and more efficient support of legacy [[Carbon (API)|Carbon]] and [[Classic (Mac OS X)|Classic]] code; [[QuickDraw]]-based applications use bitmapped drawing exclusively.

[[de:Display Postscript]]

== See also ==

* [[NeWS]], a similar window system that used the PostScript graphic model, but with extensions for concurrency, events and OOP

* [[PostScript Standard Encoding]] (PostScript character set)

* [[NeXT character set]]

==References==

===Citations===

{{Reflist}}

===Bibliography===

* {{cite book

|title=PostScript LanguageReference Manual, SECOND EDITION

|publisher=Abobe Systems

|date=December 1990

|url=https://www.os2site.com/sw/dev/openwatcom/docs/postscript_level_2_reference_manual.pdf

|ref=CITEREFAdobe1990

}}

== Further reading ==

*<!-- <ref name="Adobe_PLRM2"> -->{{cite book |title=PostScript Language Reference Manual |edition=2nd |date=1990 |orig-year=1985 |author=Adobe Systems Incorporated |author-link=Adobe Systems Incorporated |publisher=[[Addison-Wesley Publishing Company]]}} (NB. This edition also contains a description of Display PostScript, which is no longer discussed in the third edition.)<!-- </ref> -->

== External links ==

* [http://c2.com/cgi/wiki?DisplayPostscript Description at C2 Wiki]

* [http://www.nongnu.org/backbone/ GNU/BackBone]

* [http://www.adobe.com/devnet/pdf/pdf_reference.html The most recent PDF specification, version 1.7]

* [https://web.archive.org/web/20060603154639/http://partners.adobe.com/public/developer/en/ps/psrefman.pdf PostScript Language Reference, Second Edition]

* [https://web.archive.org/web/20080515120658/http://partners.adobe.com/public/developer/ps/sdk/index_archive.html#dps Display PostScript reference documents]

* [https://www.donhopkins.com/home/archive/NeWS/leffler.text.txt Comparison between Display PostScript and NeWS]

{{XWinSys}}

[[Category:NeXT]]

[[Category:PostScript]]

[[Category:Discontinued software]]