[Commit] papers/xr_ols2003 implementation.tex,NONE,1.1 api.tex,1.11,1.12 future.tex,1.2,1.3 introduction.tex,1.14,1.15 xr_ols2003.tex,1.8,1.9

Carl Worth commit@keithp.com
Fri, 16 May 2003 11:51:43 -0700


Committed by: cworth

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

Modified Files:
	api.tex future.tex introduction.tex xr_ols2003.tex 
Added Files:
	implementation.tex 
Log Message:
Added implementation

--- NEW FILE: implementation.tex ---
\section{Implementation}

As currently implemented, Xr has good support for all functions
described here. The major aspects of the PostScript imaging model that
have not been discussed are text/font support, clipping, and color
management. Xr does include some level of experimental support for
text and clipping already, but these areas need further development.

The Xr system is implemented as 3 major library components: libXr,
libXc, and libIc. LibXr provides the user-level API described in
detail already.

LibXc is the backend of the Xr system. It provides a uniform, abstract
interface to several different low-level graphics systems. Currently,
libXc provides support for drawing to the X Window System or to
in-memory images. The semantics of the libXc interface are consistent
with the X Render Extension so it is used directly whenever available.

LibIc is an image compositing library that is used by libXc when
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
low-level system. This is the approach libXc uses to draw to an X
server that does not support the X Rendering 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
be useful to convert any X server using that implementation to instead
use libIc.

These three libraries are implemented in approximately 7000 lines of C
code.



Index: api.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/api.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- api.tex	16 May 2003 16:58:13 -0000	1.11
+++ api.tex	16 May 2003 18:51:41 -0000	1.12
@@ -58,11 +58,10 @@
 passed as the first argument to almost all other Xr functions.
 
 Before any drawing functions may be called, Xr must be provided with a
-target surface to receive the resulting graphics. Xr has the potential
-to support any of several different types of graphics targets as
-supported by the Xc backend. Currently, Xr/Xc have support for
-rendering to in-memory images as well as to any X Window System
-``drawable'', (eg. a window or a pixmap).
+target surface to receive the resulting graphics. The backend of Xr
+has support for multiple types of graphics targets. Currently, Xr has
+support for rendering to in-memory images as well as to any X Window
+System ``drawable'', (eg. a window or a pixmap).
 
 The program calls XrSetTargetImage to direct graphics to an array of
 bytes arranged as 4-byte ARGB pixels. A similar call,

Index: future.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/future.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- future.tex	16 May 2003 18:24:28 -0000	1.2
+++ future.tex	16 May 2003 18:51:41 -0000	1.3
@@ -6,28 +6,28 @@
 
 \subsection{Text Support}
 
-Much of the current design effort has been focused on high level drawing
-model and some low level rendering implementation for geometric primitives.
-That was simplified by the adoption of the PostScript model.  PostScript
+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
 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 use the FreeType~\cite{freetype2} library
+plan is to require applications to use the FreeType~\cite{freetype2} library
 for font access and the Fontconfig~\cite{fontconfig} library for font
 selection and matching.  That should leave Xr needing only relatively
-primitive support for positioning glyphs and push issues of layout back on
+primitive support for positioning glyphs and will push issues of layout back on
 the application.
 
 \subsection{Printing Backend}
 
-Xr is current able to draw to the window system using the RENDER extension
-and also draw to local images.  What's missing is the ability to generate
+Xr is currently able to draw to the window system using the RENDER extension
+and 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
 essential similarity between the two existing backends.
 
 One of the goals of Xr is to have identical output across all output
-devices, this will require that Xr embed glyph images along with the
+devices. This will require that Xr embed glyph images along with the
 document output to ensure font matching across all PostScript or PDF
 interpreters.  Embedding TrueType and Type1 fonts in the output file should
 help solve this problem.
@@ -39,6 +39,6 @@
 necessary to eventually include support for more sophisticated color
 management, such development will certainly await a compelling need.  One
 simple thing to do in the meantime would be to reinterpret the
-device-dependent RGB values currently provide as sRGB instead.  Using ICC
+device-dependent RGB values currently provided as sRGB instead.  Using ICC
 color profiles would permit reasonable color matching across devices while
 not adding significant burden to the API or implementation.

Index: introduction.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/introduction.tex,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- introduction.tex	16 May 2003 18:30:59 -0000	1.14
+++ introduction.tex	16 May 2003 18:51:41 -0000	1.15
@@ -94,7 +94,7 @@
 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
+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.

Index: xr_ols2003.tex
===================================================================
RCS file: /local/src/CVS/papers/xr_ols2003/xr_ols2003.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- xr_ols2003.tex	16 May 2003 16:04:14 -0000	1.8
+++ xr_ols2003.tex	16 May 2003 18:51:41 -0000	1.9
@@ -33,6 +33,7 @@
 \input{abstract}
 \input{introduction}
 \input{api}
+\input{implementation}
 \input{related}
 \input{future}
 \input{acknowledgements}