[Commit] papers/xr_ols2003 api.tex,1.17,1.18 appendix.tex,1.11,1.12 future.tex,1.4,1.5 implementation.tex,1.1,1.2 introduction.tex,1.16,1.17 related.tex,1.3,1.4
Carl Worth
commit@keithp.com
Fri, 16 May 2003 18:41:55 -0700
Committed by: cworth
Update of /local/src/CVS/papers/xr_ols2003
In directory home.keithp.com:/tmp/cvs-serv29651
Modified Files:
api.tex appendix.tex future.tex implementation.tex
introduction.tex related.tex
Log Message:
Final batch of minor corrections. Should be ready to ship now.
Index: api.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/api.tex,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- api.tex 16 May 2003 19:55:44 -0000 1.17
+++ api.tex 17 May 2003 01:41:53 -0000 1.18
@@ -6,8 +6,8 @@
This section provides a tour of the application programming interface
(API) provided by Xr. Major features of the API are demonstrated in
-illustrations along with source code sufficient to produce each
-illustration.
+illustrations, and the source code for each illustration is provided
+in Appendix~\ref{sec:source_code}.
\subsection{Xr Initialization}
@@ -80,14 +80,14 @@
\label{sec:transformations}
All coordinates passed from user code to Xr are in a coordinate system
-known as ``user space''. These coordinates must be transformed to
+known as ``user space''. These coordinates are then transformed to
``device space'' which corresponds to the device grid of the target
surface. This transformation is controlled by the current
transformation matrix (CTM) within Xr.
-The initial matrix is established such that one user unit maps to an
+The initial CTM is established such that one user unit maps to an
integer number of device pixels as close as possible to 3780 user
-units per meter (~96 DPI) of physical device. This approach attempts to
+units per meter (\~{}96 DPI) of physical device. This approach attempts to
balance the competing desires of having a predictable real-world
interpretation for user units and having the ability to draw elements
on exact device pixel boundaries. Ideally, device pixels would be so
@@ -140,9 +140,7 @@
draw_something (XrState *xrs)
{
XrSave (xrs);
-
/* draw something here */
-
XrRestore (xrs);
}
\end{verbatim}
@@ -162,7 +160,7 @@
path. A path consists of one or more independent subpaths, each of
which is an ordered set of straight or curved segments. Any non-empty
path has a ``current point'', the final coordinate in the final
-segment of the current subpath. All path construction functions both
+segment of the current subpath. Path construction functions may
read and update the current point.
Xr provides several functions for constructing paths. XrNewPath
@@ -180,9 +178,9 @@
XrClosePath closes the current subpath. This operation
involves adding a straight line segment from the current point to the
initial point of the current subpath, (ie. the point specified by the most
-recent call to XrMoveTo or XrRelMoveTo). Calling XrClosePath is not
-equivalent to adding the corresponding line segment with XrLineTo or
-XrRelLineTo. The distinction is that a closed subpath will have a join
+recent call to XrMoveTo). Calling XrClosePath is not
+equivalent to adding the corresponding line segment with XrLineTo.
+The distinction is that a closed subpath will have a join
at the junction of the final coincident point while an unclosed path
will have caps on either end of the path, (even if the two ends happen
to be coincident). See Section~\ref{sec:path_stroking} for more
@@ -228,9 +226,9 @@
in user space is circular with a radius of the current line width, (as
set by XrSetLineWidth). The specification of the XrStroke operator is
based on the convolution of polygonal tracings as set forth by Guibas,
-Ramshaw and Stolfi~\cite{ramshaw83}. Convolution lends itself to an
+Ramshaw and Stolfi~\cite{ramshaw83}. Convolution lends itself to
efficient implementation as the outline of the stroke can be computed
-within an arbitrarily small error bound by simply using a piece-wise
+within an arbitrarily small error bound by simply using piece-wise
linear approximations of the path and the pen.
As subsequent segments within a subpath are drawn, they are connected
@@ -283,15 +281,14 @@
XrSetTolerance function allows the user to specify a maximum error in
units of device pixels.
-The tolerance value has a strong impact on the quality of antialiased
-splines. Empirical testing with modern displays revealed that users
-could detect errors as larger than 0.1 device pixels
+The tolerance value has a strong impact on the quality of rendered
+splines. Empirical testing with modern displays reveals that errors
+larger than 0.1 device pixels are observable. The default tolerance
+value in Xr is therefore 0.1 device pixels.
-The default tolerance in Xr is 0.1 device pixels, as errors larger
-than 0.1 pixels were determined empirically to be noticeable on a 100
-DPI display. The user can increase the tolerance value to tradeoff
+The user can increase the tolerance value to tradeoff
rendering accuracy for performance. Figure~\ref{fig:splines_tolerance}
-display the same curved path rendered several times with increasing
+displays the same curved path rendered several times with increasing
tolerance values. Figure~\ref{fig:splines_tolerance_source} contains
the source code for this figure.
@@ -307,8 +304,8 @@
\subsection{Paint}
\label{sec:paint}
-The examples shown so far have all used opaque ``paint'' as the
-source for all drawing operations. The color of this paint is selected
+The example renderings shown so far have all used opaque ``paint'' as the
+source color for all drawing operations. The color of this paint can be controlled
with the XrSetRGBColor function.
Xr supports more interesting possibilities for the paint used in
@@ -320,7 +317,7 @@
number of different ways in which the source and destination colors
can be combined. Xr provides support for all of the Porter/Duff
compositing operators as well as the extended operators defined in the
-X Render extension. The desired operator is selected by calling
+X Render Extension. The desired operator is selected by calling
XrSetOperator before compositing. The default operator value is
XrOperatorOver corresponding to the Porter/Duff OVER operator.
@@ -348,10 +345,10 @@
\label{sec:images}
In addition to the vector path support, Xr also supports bitmapped
-images as a primitive object. Images are transformed, (and optionally
+images as primitive objects. Images are transformed, (and optionally
filtered), by the CTM in the same manner as all other primitives. In
order to display an image, an XrSurface object must first be created
-for the image, then the image can be displayed with the XrShowSurface
+for the image, then the surface can be displayed with the XrShowSurface
function. XrShowSurface places an image of the given width and height
at the origin in user space, so XrTranslate can be used to position
the surface.
@@ -371,9 +368,9 @@
\begin{scriptsize}
\begin{verbatim}
XrSave (xrs);
-XrSetTargetSurface (xrs, intermediate);
+XrSetTargetSurface (xrs, surface);
/* draw to intermediate surface with
- any Xr operations */
+ any Xr functions */
XrRestore (xrs);
XrShowSurface (xrs, surface);
\end{verbatim}
@@ -387,7 +384,7 @@
This technique can be applied recursively with any number of levels of
intermediate surfaces each receiving the results of its ``child''
-surfaces before being composited into its ``parent'' surface.
+surfaces before being composited onto its ``parent'' surface.
Alternatively, images can be constructed from data external to the Xr
environment, acquired from image files, external devices or even the
Index: appendix.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/appendix.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- appendix.tex 16 May 2003 20:21:46 -0000 1.11
+++ appendix.tex 17 May 2003 01:41:53 -0000 1.12
@@ -1,13 +1,14 @@
\appendix
\section{Example Source Code}
+\label{sec:source_code}
This appendix contains the source code that was used to draw each
figure in Section~\ref{sec:api}. Each example contains a top-level
-``draw'' function that accepts and XrState pointer, a width, and a
-height. The examples here can be made complete programs by adding the
+``draw'' function that accepts an XrState pointer, a width, and a
+height. The examples here can be made into complete programs by adding the
code from the example program of Figure~\ref{fig:source_minimal} and
-inserting a call to the ``draw'' function.
+inserting a call to the appropriate ``draw'' function.
\begin{figure}[htbp]
\begin{scriptsize}
@@ -53,7 +54,7 @@
}
\end{verbatim}
\end{scriptsize}
-\caption{Source for Hering illusion}
+\caption{Source for Hering illusion of Figure~\ref{fig:hering}}
\label{fig:hering_source}
\end{figure}
@@ -113,7 +114,7 @@
}
\end{verbatim}
\end{scriptsize}
-\caption{Source for cap and join demonstration}
+\caption{Source for cap and join demonstration of Figure~\ref{fig:caps_joins}}
\label{fig:caps_joins_source}
\end{figure}
@@ -144,7 +145,7 @@
}
\end{verbatim}
\end{scriptsize}
-\caption{Source for nested box illusion}
+\caption{Source for nested box illusion of Figure~\ref{fig:spiral}}
\label{fig:spiral_source}
\end{figure}
@@ -184,7 +185,7 @@
}
\end{verbatim}
\end{scriptsize}
-\caption{Source for splines drawn with varying tolerance}
+\caption{Source for splines drawn with varying tolerance as in Figure~\ref{fig:splines_tolerance}}
\label{fig:splines_tolerance_source}
\end{figure}
@@ -234,7 +235,7 @@
}
\end{verbatim}
\end{scriptsize}
-\caption{Source for stars to demonstrate fill rule}
+\caption{Source for stars to demonstrate fill rule as in Figure~\ref{fig:stars}}
\label{fig:stars_source}
\end{figure}
@@ -354,6 +355,6 @@
\end{verbatim}
\end{minipage}
\end{scriptsize}
-\caption{Source for 3 gradient-filled shapes}
+\caption{Source for 3 gradient-filled shapes of Figure~\ref{fig:outline}}
\label{fig:outline_source}
\end{figure*}
Index: future.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/future.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- future.tex 16 May 2003 19:12:05 -0000 1.4
+++ future.tex 17 May 2003 01:41:53 -0000 1.5
@@ -8,7 +8,7 @@
Much of the current design effort has been focused on the high-level drawing
model and some low-level rendering implementation for geometric primitives.
-The design effor was simplified by the adoption of the PostScript model. PostScript
+This design effort was simplified by the adoption of the PostScript model. PostScript
offers a few useful suggestions about handling text, but applications
require significantly more information about fonts and layout. The current
plan is to require applications to use the FreeType~\cite{freetype2} library
@@ -19,8 +19,8 @@
\subsection{Printing Backend}
-Xr is currently able to draw to the window system using the X Render Extension
-and also draw to local images. Still missing is the ability to generate
+Xr is currently able to draw to the X Window System, (with or without the X Render Extension),
+and can also draw to local images. Still missing is the ability to generate
PostScript or PDF output files. Getting this working is important not only
so that applications can print, but also because there may be unintended
limitations in both the implementation and specification caused by the
Index: implementation.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/implementation.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- implementation.tex 16 May 2003 18:51:41 -0000 1.1
+++ implementation.tex 17 May 2003 01:41:53 -0000 1.2
@@ -20,12 +20,12 @@
drawing to in-memory images. LibIc can also be used to provide support
for a low-level system whose semantics do not match the libXc
interface. In this case, libIc is used to draw everything to an
-in-memory image and then the resulting image is given provided to the
+in-memory image and then the resulting image is provided to the
low-level system. This is the approach libXc uses to draw to an X
-server that does not support the X Rendering Extension.
+server that does not support the X Render Extension.
The libIc code is based on the original code for the software fallback
-in the reference implementation of the X Rendering Extension. It would
+in the reference implementation of the X Render Extension. It would
be useful to convert any X server using that implementation to instead
use libIc.
Index: introduction.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/introduction.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- introduction.tex 16 May 2003 19:09:53 -0000 1.16
+++ introduction.tex 17 May 2003 01:41:53 -0000 1.17
@@ -7,15 +7,15 @@
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 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.
+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\cite{x} to a complete device-independent rendering environment should
+System to a complete device-independent rendering environment should
serve to drive future application development in exciting directions.
\subsection{Vector Graphics}
Index: related.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/related.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- related.tex 16 May 2003 18:53:28 -0000 1.3
+++ related.tex 17 May 2003 01:41:53 -0000 1.4
@@ -5,7 +5,7 @@
\subsection{PostScript and Display PostScript}
-As described in the Introduction, Xr adopts (and extends) the 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
@@ -13,14 +13,14 @@
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 disadvangage is that images are never
+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
+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.