[Commit] papers/xr_ols2003 introduction.tex,1.5,1.6

[Keith Packard]

Committed by: keithp

Update of /local/src/CVS/papers/xr_ols2003
In directory home.keithp.com:/tmp/cvs-serv20355

Modified Files:
	introduction.tex 
Log Message:
Shuffle text about a bit, add new subsections

Index: introduction.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/introduction.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- introduction.tex	16 May 2003 03:15:28 -0000	1.5
+++ introduction.tex	16 May 2003 04:38:47 -0000	1.6
@@ -1,31 +1,27 @@
 \section{Introduction}
 
-\subsection{Vector Graphics}
-
-\subsection{Xr Programming Interface}
+The design of the Xr library is motivated by the desire to provide a
+high-quality rendering interface for all areas of application presentation,
+from labels and shading on buttons to the central image manipulation in a
+drawing or painting program.  The existing X-based rendering infrastructure
+has provided barely enough capability to draw buttons and sliders, moving
+from that to a complete rendering environment should serve to drive future X
+application development in exciting directions.
 
-While the goal of the Xr library is to provide a PDF 1.4 imaging model, PDF
-doesn't provide any programming language interface.  Xr borrows it's
-imperative immediate mode model from PostScript operators.  However, instead
-of proposing a complete new programming language to encapsulate these
-operators, Xr uses C functions for the operations and expects the developer
-to use C instead of PostScript to implement the application part of the
-rendering system.  This dramatically reduces the number of operations needed
-by the library as only those directly involved in graphics need be
-provided.  The large number of PostScript operators that support a complete
-language are more than adequately replaced by the C programming language.
+\subsection{Vector Graphics}
 
-PostScript encapsulates rendering state in a global opaque object and
-provides simple operators to change various aspects of that state, from
-color to line width and dash patterns.  Because global objects can cause
-various problems in C library interfaces, the graphics state in Xr is held
-in a structure that is passed to each of the library functions.
+On modern display hardware, an applications desire to present information
+using abstract geometric objects must be translated to physical pixels at
+some point in the process.  The later this transition occurs in the
+rendering process the fewer pixelization artifacts will appear as a result of
+additional transformation operations on pixel-based data.
 
-The translation from PostScript operators to the Xr interface is
-straightforward.  For example, the \texttt{lineto} operator translates to
-the \texttt{XrLineTo} function.  The coordinates of the line endpoint needed
-by the operator are preceded by the graphics state object in the Xr
-interface.
+Existing application artwork is often generated in pixel format because the
+rendering operations available to the application at runtime are a mere
+shadow of those provided in a typical image manipulation program.  Providing
+sufficient rendering functionality within the application envioronment
+allows artwork to be provided in vector form which presents high quality
+results at a wide range of sizes.
 
 % I thought it might be nice to get tux onto the front page.
 % Maybe a discussion/comparison of raster vs. vector image descriptions
@@ -67,3 +63,47 @@
 % (http://www.isc.tamu.edu/~lewing/linux/). Vectorized version by Larry
 % Budig (http://www.home.unix-ag.org/simon/penguin/).
 
+\subsection{Vector Rendering Model}
+
+The two-dimensional graphics world is fortunate to have one dominant
+rendering model.  With the introduction of desktop publishing and the
+PostScript printer, application developers converged on that model.  Recent
+extensions to that model have been incorporated in PDF 1.4, but the basic
+architecture remains the same.  PostScript provides a simple painters model;
+each rendering operation replaces the contents of the surface with a new
+image.  PDF 1.4 extends this model to include Porter/Duff image compositing
+and other image manipulation operations which serve to bring the basic
+PostScript rendering model in line with modern application demands.
+
+PostScript and PDF draw geometric shapes by constructing arbitrary paths of
+lines and cubic Bezier splines.  The coordinates used for the construction
+can be transformed with an affine matrix.  This provides a powerful
+compositing technique as the transformation may be set before a complex
+object is drawn to position and scale it appropriately.  Text is treated as
+pre-built path sections which couples it tightly and clealy with the rest of
+the model.
+
+\subsection{Xr Programming Interface}
+
+While the goal of the Xr library is to provide a PDF 1.4 imaging model, PDF
+doesn't provide any programming language interface.  Xr borrows it's
+imperative immediate mode model from PostScript operators.  However, instead
+of proposing a complete new programming language to encapsulate these
+operators, Xr uses C functions for the operations and expects the developer
+to use C instead of PostScript to implement the application part of the
+rendering system.  This dramatically reduces the number of operations needed
+by the library as only those directly involved in graphics need be
+provided.  The large number of PostScript operators that support a complete
+language are more than adequately replaced by the C programming language.
+
+PostScript encapsulates rendering state in a global opaque object and
+provides simple operators to change various aspects of that state, from
+color to line width and dash patterns.  Because global objects can cause
+various problems in C library interfaces, the graphics state in Xr is held
+in a structure that is passed to each of the library functions.
+
+The translation from PostScript operators to the Xr interface is
+straightforward.  For example, the \texttt{lineto} operator translates to
+the \texttt{XrLineTo} function.  The coordinates of the line endpoint needed
+by the operator are preceded by the graphics state object in the Xr
+interface.