Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!nrl-cmf!ames!pasteur!ucbvax!decwrl!adobe!ondine!greid
From: greid@ondine.COM (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: Display PostScript
Message-ID: <4052@adobe.COM>
Date: 29 Jun 88 22:38:33 GMT
References: <336@uva.UUCP> <1089@ssc-bee.ssc-vax.UUCP> <511@sequent.cs.qmc.ac.uk>
Sender: news@adobe.COM
Reply-To: greid@ondine.UUCP (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 84

Thank you for the overview of Display PostScript, first of all.  It is
a pretty good interpretation of the overview document mentioned
(available from our server as Documents/DPSoverview.ps).  Since we
are participants in this forum, I welcome any questions about Display
PostScript, since it is difficult sometimes to sort fact from fiction.
I'll do my best to paint a clear picture of the product.

Below are some brief responses to William Roberts' comments, but first
let me add a little to the overview.

The procedural interface to the Display PostScript interpreter, dubbed
"PSWrap," allows you to write PostScript language code and compile it
into your application with a C interface calling convention.  The C
code generated by PSWrap will, when executed, send bursts of digested
PostScript code to the server for interpretation.  The server, as a
separate process, will generally execute this code asynchronously.

The approach will be to develop applications in C, not in PostScript.
Most of the work of the application is done in C by the application
program, and when it is time to display something, you make a call
either to a built-in Display PostScript client library routine or to
one of your own PSWrap routines to communicate with the Display
PostScript server.  This offloads all of the device-dependent aspects
of supporting displays, especially with fonts, which are handled
exactly as they are in the printer PostScript environment (as outline
fonts, referenced simply by name and point size).  The entire font
library will work on the displays without modification.  There are no
WYSIWYG problems with font scaling or interpolating from bitmapped
fonts, and the results are the same as would be obtained on the
printer.  Also, you don't have to figure out N different screen font
representations or environment-specific text-setting routines.

The Display PostScript System is not intended as a new "development
environment", but as an integral part of the operating system display
technology that can be largely invisible to application development.
In much the same way that programs do not need to be recompiled to deal
with different keyboards today, they will not need to be recompiled for
different display technologies tomorrow, with the Display PostScript
System.

The PostScript language has been enhanced in several ways to support
the more dynamic requirements of displays, including repeated execution
of objects, repainting, font handling, and so forth.  It also has full
garbage collection and management of shared resources (like fonts,
primarily).  I can't give you a lot of detail on the language
extensions yet, unfortunately.

Anyway, here are some quick responses to William's message:

>The Display PostScript interpreter does not provide logically separate
>PostScript environments.
	Yes, it does.  They are "contexts", and there can
	be any number of them.  Each context has its own environment,
	including separate stacks, VM, graphics state, etc., although
	resources can be shared either through the "sharedVM"
	facility or though explicit sharing between processes.
	
>			PostScript code can be shared between "windows"
>by a shared memory scheme, hence save/restore is no longer adequate and
>garbage collection is introduced. Each window is a separate context, and
>the interpreter can switch between these contexts. It is not clear
>whether or not "multi-tasking" means more than this: if so, it probably
>means that the interpreter executes PostScript asynchronously on behalf
>of the application, and interleaves the execution of code in different
>contexts.
	Basically, yes.  Processes can also be spawned individually.

>Almost all of the other information merely recites the benefits of
>ordinary PostScript.
	Of course, what is wonderful about Display PostScript is that the
	benefits of ordinary PostScript are going to be available
	for displays, which should solve many of the development
	problems associated with supporting specific hardware.
	
>			There is no concept of "input" in Display
>PostScript whatsoever, and the cheap stab at NeWS is not particularily
>becoming....
	Not a cheap stab, but a pointed clarification of a difference
	that is not often clearly understood.  We are only concerning
	ourselves with imaging.

Glenn Reid
Adobe Systems
PostScript Software Division