[Commit] papers/xr_ols2003 api.tex,1.5,1.6 introduction.tex,1.7,1.8 xr_ols2003.tex,1.4,1.5
Carl Worth
commit@keithp.com
Thu, 15 May 2003 21:56:04 -0700
Committed by: cworth
Update of /local/src/CVS/papers/xr_ols2003
In directory home.keithp.com:/tmp/cvs-serv20489
Modified Files:
api.tex introduction.tex xr_ols2003.tex
Log Message:
Fixed description of default matrix.
Added description of XrSetTolerance.
Fixed some minor things in the introduction.
Index: api.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/api.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- api.tex 16 May 2003 00:32:34 -0000 1.5
+++ api.tex 16 May 2003 04:56:02 -0000 1.6
@@ -1,5 +1,8 @@
\section{API and Examples}
+% Not to discuss for various reasons of brokenness: XrSetDash,
+% XrClip, XrScaleFont, XrSelectFont, XrSetTolerance
+
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
@@ -91,6 +94,16 @@
surface. This transformation is controlled by the current
transformation matrix (CTM) within Xr.
+The initial matix 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 (~96DPI) 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
+small that the user could ignore pixel boundaries, but with current
+display pixel sizes of about 100 DPI, the pixel boundaries are still
+significant.
+
Initially, the CTM in Xr is an identity matrix, so user space will
initially align with device space, (with the origin at the upper-left
corner of the surface, the X axis increasing to the right, and the Y
@@ -161,7 +174,7 @@
order to begin a new subpath.
XrLineTo adds a straight line segment to the current path, from the
-current point to the point specified. XrCurveTo adds a cubic Bezier
+current point to the point specified. XrCurveTo adds a cubic B\'ezier
spline with a control polygon defined by the current point as well as
the three points specified.
@@ -260,6 +273,43 @@
% It's in Seckel page 286 and on Watanabe's web site:
% http://www.let.kumamoto-u.ac.jp/watanabe/Watanabe-E/Illus-E/3D-E/index.html
+\subsection{Controlling Accuracy}
+
+The graphics rendering of Xr is carefully implemented to allow all
+rendering approximations to be performed within a user-specified error
+tolerance, (within the limits of machine arithmetic of course). The
+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 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
+rendering accuracy for performance. Figure~\ref{fig:splines_tolerance}
+display the same curved path rendered several times with increasing
+tolerance values.
+
+\begin{figure}[htbp]
+ \begin{center}
+ \epsfxsize=2in
+ \epsfbox{examples/splines_tolerance}
+ \caption{Spline drawn with tolerance of .1, .5, 1, 5, and 10}
+ \label{fig:splines_tolerance}
+ \end{center}
+\end{figure}
+
+\subsection{Images}
+
+XXX: Discuss XrShowSurface
+
+\subsection{Paint}
+\label{sec:paint}
+
+XXX: Discuss XrSetRGBColor, XrSetAlpha, XrSetOperator, XrSetPattern
+
\begin{figure}[htbp]
\begin{center}
\epsfxsize=1in
@@ -268,9 +318,6 @@
\label{fig:line_width_example}
\end{center}
\end{figure}
-
-\subsection{Using Patterns}
-\label{sec:patterns}
\begin{figure}[htbp]
\begin{center}
Index: introduction.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/introduction.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- introduction.tex 16 May 2003 04:40:23 -0000 1.7
+++ introduction.tex 16 May 2003 04:56:02 -0000 1.8
@@ -10,7 +10,7 @@
\subsection{Vector Graphics}
-On modern display hardware, an applications desire to present information
+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
@@ -70,23 +70,23 @@
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
+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.
PostScript and PDF draw geometric shapes by constructing arbitrary paths of
-lines and cubic Bezier splines. The coordinates used for the construction
+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 clealy with the rest of
+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 it's
+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
Index: xr_ols2003.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/xr_ols2003.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- xr_ols2003.tex 15 May 2003 17:34:17 -0000 1.4
+++ xr_ols2003.tex 16 May 2003 04:56:02 -0000 1.5
@@ -33,6 +33,8 @@
\input{abstract}
\input{introduction}
\input{api}
+\input{related}
+\input{future}
\input{appendix}