Content deleted Content added
→References: +bib |
→Design: cited |
||
Line 9:
== Design ==
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 processor on the printer and the amount of memory needed. 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}}
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 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.
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}}
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}}
Finally, DPS added the concept of a {{code|pswrap}}, a[[C (programming language)|C-language]] function that took DPS commands in the form of strings and sent them to the DPS context to be output. This allowed, for instance, one to write a C-language function that produced a rectangle on the screen.{{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 [[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}}
| |||