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


1.6
date	2003.05.17.13.11.02;	author cworth;	state Exp;
branches;
next	1.5;

1.5
date	2003.05.17.01.41.53;	author cworth;	state Exp;
branches;
next	1.4;

1.4
date	2003.05.16.19.12.05;	author keithp;	state Exp;
branches;
next	1.3;

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

1.2
date	2003.05.16.18.24.28;	author keithp;	state Exp;
branches;
next	1.1;

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


desc
@@


1.6
log
@Added aavailability information
@
text
@\section{Future Work}

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.

\subsection{Text Support}

Much of the current design effort has been focused on the high-level drawing
model and some low-level rendering implementation for geometric primitives.
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
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 will push issues of layout back on
the application.

\subsection{Printing Backend}

Xr is currently able to target the X Window System, (with or without the X Render Extension),
as well as 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
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 become
necessary to add 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 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.
@


1.5
log
@Final batch of minor corrections. Should be ready to ship now.
@
text
@d22 2
a23 2
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
d38 2
a39 2
aspects of the library interface and implementation.  While it might be
necessary to eventually include support for more sophisticated color
@


1.4
log
@Fix capitalization
@
text
@d11 1
a11 1
The design effor was simplified by the adoption of the PostScript model.  PostScript
d22 2
a23 2
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
@


1.3
log
@Added implementation
@
text
@d22 1
a22 1
Xr is currently able to draw to the window system using the RENDER extension
@


1.2
log
@Add some future work, and a fontconfig ref
@
text
@d9 3
a11 3
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
d14 1
a14 1
plan is to require applications use the FreeType~\cite{freetype2} library
d17 1
a17 1
primitive support for positioning glyphs and push issues of layout back on
d22 2
a23 2
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
d30 1
a30 1
devices, this will require that Xr embed glyph images along with the
d42 1
a42 1
device-dependent RGB values currently provide as sRGB instead.  Using ICC
@


1.1
log
@Added future.tex
@
text
@d3 3
a5 1
XXX: PDF backend
d7 38
a44 1
XXX: Real text support
@