head	1.5;
access;
symbols;
locks; strict;
comment	@% @;


1.5
date	2003.05.17.13.11.02;	author cworth;	state Exp;
branches;
next	1.4;

1.4
date	2003.05.17.01.41.53;	author cworth;	state Exp;
branches;
next	1.3;

1.3
date	2003.05.16.18.53.28;	author keithp;	state Exp;
branches;
next	1.2;

1.2
date	2003.05.16.17.58.15;	author keithp;	state Exp;
branches;
next	1.1;

1.1
date	2003.05.16.06.49.38;	author cworth;	state Exp;
branches;
next	;


desc
@@


1.5
log
@Added aavailability information
@
text
@\section{Related Work}

Of the many existing graphics systems, several relate directly to this
new work.  

\subsection{PostScript and Display PostScript}

As described in the introduction, Xr adopts (and extends) the PostScript
rendering model.  However, PostScript is not just a rendering model as it
includes a complete programming language.  Display PostScript embeds a
PostScript interpreter inside the window system.  Drawing is done
by generating PostScript programs and delivering them to the window system.

One obvious benefit of using PostScript everywhere is that printing and
display can easily be done with the same rendering code, as long as the
printer supports PostScript.  A disadvantage is that images are never
generated within the application address space making it more difficult to
use where PostScript is not available.

Using the full PostScript language as an intermediate representation means
that a significant fraction of the overall application development will be
done in this primitive language.  In addition, the PostScript portion is
executed asynchronously with respect to the remaining code, further
complicating development.  Integrating the powerful PostScript rendering
model into the regular application development language provides a coherent
and efficient infrastructure.

\subsection{Portable Document Format}

PDF provides a very powerful rendering model, but no application interface.
Generating PDF directly from an application would require some kind of PDF
API along with a PDF interpreter.  The goal for Xr is to be able to generate
PDF output files while providing a clean application interface.

A secondary goal is to allow PDF interpreters to be implemented on top of
Xr.  As Xr is missing some of the less important PDF operations, those will
need to be emulated within the interpreter.  An important feature within Xr
is that such emulation be reasonably efficient.

\subsection{OpenGL}

OpenGL\cite{gl:1.2.1} provides an API with much the same flavor as Xr;
immediate mode functions with an underlying stateful library.  OpenGL
doesn't provide the PostScript rendering model, and doesn't purport to
support printing or the local generation of images.

As Xr provides an abstract interface atop many graphics architectures, it
should be possible to layer Xr on OpenGL.

@


1.4
log
@Final batch of minor corrections. Should be ready to ship now.
@
text
@d48 1
a48 2
should be possible to layer Xr on OpenGL.  For high performance OpenGL
implementations, this may well be a good direction.
@


1.3
log
@wordo
@
text
@d8 1
a8 1
As described in the Introduction, Xr adopts (and extends) the PostScript
d16 1
a16 1
printer supports PostScript.  A disadvangage is that images are never
d23 1
a23 1
executed asynchronously with respect to the remaining code further
@


1.2
log
@cite porter/duff.  add some related work
@
text
@d48 1
a48 1
may well be possible to layer Xr on OpenGL.  For high performance OpenGL
@


1.1
log
@Added related.tex
@
text
@d3 2
a4 1
XXX: PS, PDF (Already covered in introduction?)
d6 44
a49 1
XXX: OpenGL, DPS
a50 1
XXX: libart?
@