[Commit] papers/xr_ols2003 future.tex,1.1,1.2 keithp.bib,1.3,1.4

Keith Packard commit@keithp.com
Fri, 16 May 2003 11:24:31 -0700

Committed by: keithp

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

Modified Files:
	future.tex keithp.bib 
Log Message:
Add some future work, and a fontconfig ref

Index: future.tex
RCS file: /local/src/CVS/papers/xr_ols2003/future.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- future.tex	16 May 2003 06:58:05 -0000	1.1
+++ future.tex	16 May 2003 18:24:28 -0000	1.2
@@ -1,5 +1,44 @@
 \section{Future Work}
-XXX: PDF backend
+The Xr library is in active development.  Everything described in this paper
+is currently working, but much work remains to make the library generally
+useful for application development.
-XXX: Real text support
+\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
+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
+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
+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
+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
+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.
+\subsection{Color Management}
+Xr currently supports only the RGB color space.  This simplifies many
+aspects of the library interface and implementation.  While it might be
+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
+color profiles would permit reasonable color matching across devices while
+not adding significant burden to the API or implementation.

Index: keithp.bib
RCS file: /local/src/CVS/papers/xr_ols2003/keithp.bib,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- keithp.bib	16 May 2003 16:58:13 -0000	1.3
+++ keithp.bib	16 May 2003 18:24:28 -0000	1.4
@@ -531,6 +531,17 @@
  note           = "\url{http://www.gimp.org}",
+  title = "{Font Configuration and Customization for Open Source Systems}",
+  author = "Keith Packard",
+  booktitle = "2002 Gnome User's and Developers European Conference",
+  month = "April",
+  year = 2002,
+  organization = "Gnome",
+  address = "Seville, Spain",
+  url = "\url{http://keithp.com/~keithp/talks/guadec2002/}",
  title          = "3-D Shape and Outline",
  author         = "Isao Watanabe",
@@ -543,4 +554,3 @@
   publisher = 	 {Firefly Books Ltd.},
   year = 	 {2002},