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


1.17
date	2003.05.17.01.41.53;	author cworth;	state Exp;
branches;
next	1.16;

1.16
date	2003.05.16.19.09.53;	author cworth;	state Exp;
branches;
next	1.15;

1.15
date	2003.05.16.18.51.41;	author cworth;	state Exp;
branches;
next	1.14;

1.14
date	2003.05.16.18.30.59;	author keithp;	state Exp;
branches;
next	1.13;

1.13
date	2003.05.16.17.58.15;	author keithp;	state Exp;
branches;
next	1.12;

1.12
date	2003.05.16.15.39.14;	author cworth;	state Exp;
branches;
next	1.11;

1.11
date	2003.05.16.06.58.52;	author keithp;	state Exp;
branches;
next	1.10;

1.10
date	2003.05.16.05.37.30;	author cworth;	state Exp;
branches;
next	1.9;

1.9
date	2003.05.16.05.05.52;	author keithp;	state Exp;
branches;
next	1.8;

1.8
date	2003.05.16.04.56.02;	author cworth;	state Exp;
branches;
next	1.7;

1.7
date	2003.05.16.04.40.23;	author keithp;	state Exp;
branches;
next	1.6;

1.6
date	2003.05.16.04.38.47;	author keithp;	state Exp;
branches;
next	1.5;

1.5
date	2003.05.16.03.15.28;	author keithp;	state Exp;
branches;
next	1.4;

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

1.3
date	2003.05.14.21.04.22;	author cworth;	state Exp;
branches;
next	1.2;

1.2
date	2003.05.14.15.45.00;	author cworth;	state Exp;
branches;
next	1.1;

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


desc
@@


1.17
log
@Final batch of minor corrections. Should be ready to ship now.
@
text
@\section{Introduction}

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.  Xr targets displays, printers and local image
buffers with a uniform rendering model so that applications can use the same
API to present information regardless of the media.

The Xr library provides a device-independent API, and can currently
drive X Window System\cite{x} applications as well as manipulate
images in the application address space. It can take advantage of the
X Render Extension\cite{render:2001} where available but does not
require it. The intent is to add support for Xr to produce
PostScript\cite{ps} and PDF 1.4\cite{pdf14} output.

Moving from the primitive original graphics system available in the X Window
System to a complete device-independent rendering environment should
serve to drive future application development in exciting directions.

\subsection{Vector Graphics}

On modern display hardware, an application's 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.

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 environment
allows artwork to be provided in vector form which presents high quality
results at a wide range of sizes.

\begin{figure}[htb]
  \begin{center}
  \epsfxsize=.833in
  \epsfbox{figures/tux_raster}
  \epsfxsize=.833in
  \epsfbox{figures/tux_vector}
  \caption{Raster and vector images at original size (artwork courtesy of Larry Ewing and Simon Budig)} 
  \label{fig:tux_original}
  \end{center}
\end{figure}

\begin{figure}[b!]
  \begin{center}
  \epsfxsize=1.66in
  \epsfbox{figures/tux_head_raster_4x}
  \caption{Raster image scaled 400\%}
  \label{fig:tux_raster_scaled}
  \end{center}
\end{figure}

Figures~\ref{fig:tux_original}-\ref{fig:tux_vector_scaled} illustrate
the benefits of vector artwork. The penguin on the left of
Figure~\ref{fig:tux_original} is the familiar image as originally
drawn by Larry Ewing\cite{ewing}. The penguin on the right is an Xr
rendering of vector-based artwork by Simon Budig\cite{budig} intended
to match Ewing's artwork as closely as possible. At the original scale
of the raster artwork, the two images are quite comparable.

However, when the images are scaled up, the differences between raster
and vector artwork become apparent. Figure~\ref{fig:tux_raster_scaled}
shows a portion of the original raster image scaled by a factor of 4
with the GIMP~\cite{gimp}. Artifacts from the scaling are apparent,
primarily in the jaggies around the contour of the image. The GIMP did
apply an interpolating filter to reduce these artifacts but this comes
at the cost of blurring the image. Compare this to
Figure~\ref{fig:tux_vector_scaled} where Xr has been used to draw the
vector artwork at 4 times the original scale. Since the vector artwork
is resolution independent, the artifacts of jaggies and blurring are
not present in this image.

% *sigh* I'd like to have dot-for-dot renderings of the images, so I
% would prefer not to specify a size here. But the pdflatex stuff
% that comes with the OLS template blows these up huge unless I set
% an explicit width.

\begin{figure}[b!]
  \begin{center}
  \epsfxsize=1.66in
  \epsfbox{figures/tux_head_vector_4x}
  \caption{Vector image scaled 400\%}
  \label{fig:tux_vector_scaled}
  \end{center}
\end{figure}

\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 places new paint on top of the contents of the
surface. PDF 1.4 extends this model to include Porter/Duff image
compositing~\cite{porterduff:1984} 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 B\'ezier 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 cleanly 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 its
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 lineto operator translates to
the XrLineTo function.  The coordinates of the line endpoint needed
by the operator are preceded by the graphics state object in the Xr
interface.
@


1.16
log
@Push big Tux heads together
@
text
@d10 6
a15 6
The Xr library provides a device-independent API to drive X window
system\cite{x} applications.  It can take advantage of the X Render
Extension\cite{render:2001} where available but does not require it.  The
intent is to also have Xr produce PostScript\cite{ps} and PDF
1.4\cite{pdf14} output as well as manipulate images in the application
address space.
d18 1
a18 1
System\cite{x} to a complete device-independent rendering environment should
@


1.15
log
@Added implementation
@
text
@d36 20
a79 19
\begin{figure}[htb]
  \begin{center}
  \epsfxsize=.833in
  \epsfbox{figures/tux_raster}
  \epsfxsize=.833in
  \epsfbox{figures/tux_vector}
  \caption{Raster and vector images at original size (artwork courtesy of Larry Ewing and Simon Budig)} 
  \label{fig:tux_original}
  \end{center}
\end{figure}

\begin{figure}[htbp]
  \begin{center}
  \epsfxsize=1.66in
  \epsfbox{figures/tux_head_raster_4x}
  \caption{Raster image scaled 400\%}
  \label{fig:tux_raster_scaled}
  \end{center}
\end{figure}
d81 1
a81 1
\begin{figure}[htbp]
@


1.14
log
@spelling
@
text
@d97 1
a97 1
surface PDF 1.4 extends this model to include Porter/Duff image
@


1.13
log
@cite porter/duff.  add some related work
@
text
@d49 1
a49 1
apply an iterpolating filter to reduce these artifacts but this comes
@


1.12
log
@Added reference to convolution.
Added prose around the penguin figures.
Added references for artwork by Larry Ewing and Simon Budig and the GIMP.
Removed long (and incomplete) source code for gradient example.
@
text
@d96 5
a100 4
each rendering operation places new paint on top of the contents of the surface
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.
@


1.11
log
@Add some primitive bib entries
@
text
@d36 19
a54 2
% I thought it might be nice to get tux onto the front page.
% Maybe a discussion/comparison of raster vs. vector image descriptions
d66 1
a66 1
  \caption{Raster and vector images at original size}
a87 4

% XXX: Attribution: Original raster image by Larry Ewing,
% (http://www.isc.tamu.edu/~lewing/linux/). Vectorized version by Larry
% Budig (http://www.home.unix-ag.org/simon/penguin/).
@


1.10
log
@Added source code for splines figure.
Removed \texttt from function names.
@
text
@d10 10
a19 3
Moving from the primitive original X graphics system to a complete
device-independent rendering environment should serve to drive future
application development in exciting directions.
@


1.9
log
@reword start of introduction
@
text
@d25 1
a25 1
sufficient rendering functionality within the application envioronment
d109 2
a110 2
straightforward.  For example, the \texttt{lineto} operator translates to
the \texttt{XrLineTo} function.  The coordinates of the line endpoint needed
@


1.8
log
@Fixed description of default matrix.
Added description of XrSetTolerance.
Fixed some minor things in the introduction.
@
text
@d6 6
a11 3
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
@


1.7
log
@run-on
@
text
@d13 1
a13 1
On modern display hardware, an applications desire to present information
d73 2
a74 2
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
d79 1
a79 1
lines and cubic Bezier splines.  The coordinates used for the construction
d83 1
a83 1
pre-built path sections which couples it tightly and clealy with the rest of
d89 1
a89 1
doesn't provide any programming language interface.  Xr borrows it's
@


1.6
log
@Shuffle text about a bit, add new subsections
@
text
@d7 1
a7 1
has provided barely enough capability to draw buttons and sliders, moving
@


1.5
log
@Start on introduction prose
@
text
@d3 8
d13 12
a24 24
\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.
d66 44
@


1.4
log
@Spewed some text on how to use the API
@
text
@d3 27
@


1.3
log
@Added a couple of figures along with their example code
@
text
@d39 3
a41 3
Attribution: Original raster image by Larry Ewing,
(http://www.isc.tamu.edu/~lewing/linux/). Vectorized version by Larry
Budig (http://www.home.unix-ag.org/simon/penguin/).
@


1.2
log
@Added explicit width for the figures
@
text
@d21 1
a21 1
\begin{figure}[htb]
d23 4
a26 6
  \epsfxsize=3.33in
  \epsfbox{figures/tux_raster_4x}
  \epsfxsize=3.33in
  \epsfbox{figures/tux_vector_4x}
  \caption{Raster and vector images scaled 400\%}
  \label{fig:tux_scaled}
d29 14
@


1.1
log
@Added some tux figures to the (otherwise empty) introduction
@
text
@d6 4
d12 1
d14 1
d23 1
d25 1
@