Creates a real list of projects on which help would be appreciated.

git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@229 a1074d23-0009-0410-80fe-cf8c14f379e6

1 files changed, 311 insertions, 6 deletions

diff --git a/gs/doc/Projects.htm b/gs/doc/Projects.htm
index 3fb009254..4db175509 100644
--- a/gs/doc/Projects.htm
+++ b/gs/doc/Projects.htm
@@ -22,9 +22,14 @@ Ghostscript projects seeking developers
 <h2>Table of contents</h2>
 
 <blockquote><ul>
-<li><a href="#Platforms">Additional platforms</a>
-<li><a href="#Drivers">Additional drivers</a>
-<li><a href="#Extensions">Functional extensions</a>
+<li><a href="#Platforms">Platforms</a>
+<li><a href="#Drivers">Drivers</a>
+<ul>
+<li><a href="#Driver_architecture">Architecture</a>
+<li><a href="#Specific_drivers">Specific drivers</a>
+</ul>
+<li><a href="#Graphics">Graphics</a>
+<li><a href="#Other_topics">Other topics</a>
 </ul></blockquote>
 
 <!-- [1.2 end table of contents] =========================================== -->
@@ -46,10 +51,14 @@ overview</a>.
 There are many projects that would improve Ghostscript and that we would
 like to do, but for which we don't have enough resources.  If you would like
 to take responsibility for any of these projects, please <a
-href="mailto:ghost@aladdin.com">contact us</a>.
+href="mailto:ghost@aladdin.com">contact us</a>.  Additional comments on
+implementation approaches or project goals are in <I>italic type like
+this</I>.
 
 <h1><a name="Platforms"></a>Additional platforms</h1>
 
+<h3>DOS, Windows and OS/2 builds using gcc.</h3>
+
 <p>
 We would like Ghostscript to work with the free <b><tt>emx/gcc</tt></b> and
 <b><tt>rsx</tt></b> libraries, to provide an alternative DOS, Windows
@@ -63,7 +72,80 @@ the makefiles.  If interested, please consult
 <a href="http://www.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/">http://www.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/</a>
 </blockquote>
 
-<h1><a name="Drivers"></a>Additional drivers</h1>
+<h3>Windows driver using Ghostscript as a language monitor.</h3>
+
+<p>
+MS Windows has a "language monitor" capability which would allow Ghostscript
+to be invoked seamlessly to process input files in any language Ghostscript
+could handle (currently PostScript and PDF) and for any printer for which
+Ghostscript had a driver.  Doing this properly would require integrating
+Ghostscript with Windows' "Add Printer" dialog, and would also require
+creating a PPD for Ghostscript.  <I>Russell Lang's RedMon program provides
+some, but not all, of this capability.</I>
+
+<h1><a name="Drivers"></a>Drivers</h1>
+
+<h2><a name="Driver_architecture"></a>Architecture</h2>
+
+<h3>Improved multi-threaded rendering support.</h3>
+
+<p>
+Currently, drivers can be written so that converting PostScript to a list of
+graphical objects can run in one thread, and rasterizing the objects can run
+in another thread.  However, drivers must be written specially if they are
+going to do this.  We would like to change the architecture so that any
+driver can work this way.  We would also like to support dual-threaded
+operation for drivers that produce high-level output, such as the PDF
+writer.  <I>Doing this would require separating banding from
+the multithreaded logic.  Also, currently each thread has its own allocation
+pool: this is unnecessary in the normal case, since Ghostscript now supports
+properly locked access to the C heap, but embedded systems still need to use
+a fixed-size area for the rasterizing thread.  With a locked, shared
+allocator, the rasterizing thread could use the full set of band list
+functions; with a fixed-size area and a separate allocator, only a subset is
+available, as is the case now for dual-threaded drivers.
+</I>
+
+<h3>Dynamic run-time loadable devices.</h3>
+
+<p>
+Currently, drivers must be linked into the executable.  We would like to be
+able to load drivers dynamically.  Doing this requires defining a
+platform-independent API (presumably extending the current gp_* APIs) that
+would work at least on Linux, vendor Unix, MS Windows, and Macintosh.  Unix
+systems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formats
+should both be supported.  <I>Consider the Netscape plug-in
+architecture.</I>
+
+<h3>Moving 'setpagedevice' into C.</h3>
+
+<p>
+The PostScript 'setpagedevice' function implements matching of media and
+page size requests to available media, page orientation, and paper handling
+(duplex, etc.)  Currently it is implemented in PostScript code, which means
+it is not available for use with other input languages.  (It is available
+for PDF, which Ghostscript implements on top of PostScript, but not for the
+not-yet-freely-available PCL interpreters that use the Ghostscript library,
+or for possible future SVG or similar interpreters).  We would like to move
+this function into C.  <I>The device driver will be required to
+send page parameters up to PostScript to be stored in a resource.  To be
+included in this project are handling policy implementations in the device
+drivers.  DeferredMediaSelection should also be implemented.</I>
+
+<h3>Adding 'tee' for output to multiple devices.</h3>
+
+<p>
+In a few cases, it would be desirable to provide a 'tee' capability for
+drivers: specifically, for generating small, low-resolution 'thumbnail'
+images concurrently with other output.  <I>Probably the
+simplest way to do this is to generate a band list and then process it
+twice.  This is not completely trivial, since the band list does include
+device resolution information and scaling would be required for some
+constructs.</I>
+
+<h2><a name="Specific_drivers"></a>Specific drivers</h2>
+
+<h3>PrintGear and PPA output drivers.</h3>
 
 <p>
 We would like to provide (Adobe) PrintGear and (H-P) PPA output drivers for
@@ -72,7 +154,209 @@ If you can provide them to us without violating any agreements, please let
 us know.  (Some work has already been done on reverse-engineering these
 protocols, but we don't have references to it.)
 
-<h1><a name="Extensions"></a>Functional extensions</h1>
+<h3>Improve 'pswrite' up to the level of 'pdfwrite'.</h3>
+
+<p>
+We would like to improve the high-level PostScript-writing
+<b><tt>pswrite</tt></b> driver to bring it up to parity with the PDF-writing
+driver (including the many improvements in the latter being implemented in
+Ghostscript 6.xx).  Specifically, we want it to write text as text rather
+than bitmaps, and to consistently write images in their original high-level
+form.  <I>We have already started to factor out code that
+should be common to these two drivers, specifically for writing embedded
+fonts and compressed data streams.</I>
+
+<h3>DSC comment processing for PS to PDF conversion (Distiller).</h3>
+
+<p>
+The PDF-writing driver needs to look at some of the DSC comments in the
+PostScript input.  We have a plan and design for a general DSC-reading
+capability, but we need help implementing a full DSC parser and also help
+implementing the specific set of DSC comments that the PDF writer will need
+to consider.  <I>This set is currently specified very poorly in
+the Adobe Acrobat Distiller Parameters documentation: we are working with
+Adobe to find out the details.</I>
+
+<h3>High level graphics for PCL 5 and PCL XL drivers.</h3>
+
+<p>
+Currently, the PCL 5 drivers produce only bitmaps; the PCL XL driver
+produces high-level graphics and sometimes high-level images, but low-level
+text.  We would like to improve these drivers to produce higher-level,
+smaller output.  (This is a very low-priority project.)
+
+<h3>Improved high level GDI driver for Windows.</h3>
+
+<p>
+We would like a "GDI driver" for MS Windows that would implement more
+higher-level constructs (specifically for text).  <I> The
+<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some of
+this.  Some of the the 'xfont' support code for MS Windows should be useful.
+We were frustrated in the past because the GDI calls for getting font sizes
+and metrics consistently returned incorrect information and provided no way
+to get the correct information; perhaps this has been fixed in 32-bit
+Windows.  We believe that H-P, Russell Lang, and perhaps others are working
+in this area, but we can always use more help.</I>
+
+<h3>PDF thumbnail generation.</h3>
+
+<p>
+The PDF writer needs to be able to generate thumbnails (small previews).  We
+might do this through the 'tee' capability mentioned above.  However, we
+currently prefer the idea of implementing a completely separate program to
+add thumbnails to an arbitrary, existing PDF file: this would allow
+Ghostscript to add thumbnails to PDF files generated by other programs.
+<I>Much of the code needed to do this has already been written
+for Ghostscript's PDF linearizer: see
+<b><tt>lib/pdfwrite.ps</tt></b>.  A user has implemented this as well,
+using a separate program that calls Ghostscript: see
+<a href="http://www.uni-giessen.de/~g029/eurotex99/oberdiek/">
+http://www.uni-giessen.de/~g029/eurotex99/oberdiek/</a>.
+</I>
+
+<h3>Consolidate inkjet drivers into a single family.</h3>
+
+<p>
+In addition to factoring out the error diffusion code as described below, we
+would like to see another attempt at reducing the enormous volume of code
+for color inkjet drivers.  There are three sets of drivers (gdevcdj.c,
+gdevstc.c, gdevupd.c) with much overlapping functionality.  The latter two
+driver families make good attempts at factoring out things like head
+geometry and canned control strings, but we think this problem deserves
+another pass, especially in the hope of consolidating these drivers into a
+single family.
+
+<h1><a name="Graphics"></a>Graphics</h2>
+
+<h3>Support for 64-bit colors on 64-bit platforms.</h3>
+
+<p>
+Currently, the library supports a maximum of 32 bits of data per pixel; we
+would like to raise this limit to 64 bits on systems where the 'long' data
+type is 64 bits wide.  <I>The <b><tt>gx_color_index</tt></b>
+type is already defined as 'long', but there are many places where the type
+<b><tt>bits32</tt></b> is used for pixel values; there is a 32-bit
+stored-image "device", but there is no 64-bit device; a few algorithms and
+tables have knowledge of the 32-bit width built into them, only because the
+C preprocessor doesn't have any kind of loop or repetition
+capability.</I>
+
+<h3>In-RIP trapping.</h3>
+
+<p>
+The PostScript specification includes an option for the interpreter to
+implement trapping (adjustments of object boundaries to prevent visual
+anomalies caused by slight misregistration of different ink layers): we
+would like to implement this.  <I>This is a complex and
+difficult area; even many Adobe RIPs don't do it.</I>
+
+<h3>Hook FreeType TrueType library into graphics library.</h3>
+
+<p>
+We would like to provide an option for good integration of the FreeType font
+rasterizer into Ghostscript, since the FreeType code is better than
+Ghostscript's current rasterizers.  We understand that some users in Japan
+have done this already, but we don't know if this is a good starting point
+(the only documentation is in Japanese).  <I>Their work uses
+Ghostscript's 'xfont' interface, which is how Ghostscript interfaces to
+platform facilities such as the X and MS Windows font capabilities.  This is
+a device-level interface and not the best place to do this: we would rather
+have the graphics library interface to FreeType directly.</I>
+
+<h3>ICC color space and ICC profile support.</h3>
+
+<p>
+PDF 1.3 requires direct support for ICC color profiles in the form of a new
+ICCBased color space family; we believe Adobe will add such support to
+PostScript as well.  We would like to integrate such support into the
+graphics library.  <I>This should be able to interface with the
+existing CS/CRD library code so that optimizations and improvements would
+carry into ICC color as well as CIE color.</I>
+
+<h3>Making halftones into "objects" and adding new types.</h3>
+
+<p>
+Currently, knowledge of the specific data formats and algorithms for
+halftoning permeates too many places in the library.  We would like
+halftoning to be more "object oriented" (using virtual procedures) so that
+we could support other halftoning methods such as direct use of threshold
+arrays, or the double-rectangle approach added in newer PostScript versions.
+<I>Threshold arrays take much less space than the current
+representation, generally at the expense of longer rendering time for
+black-and-white images; double-rectangle representation would give us a
+better implementation of AccurateScreens.  We might want store both
+threshold arrays and the current representation.</I>
+
+<h3>Change band list logic to defer halftoning until rendering.</h3>
+
+<p>
+Currently, when Ghostscript uses a band list, it does halftoning before
+banding.  It should do halftoning after banding: this produces smaller band
+lists and shifts more work to the rasterizer (which is good because the
+rasterizer can be multi-threaded internally for higher performance on
+multiprocessors.)
+
+<h3>Factor out error diffusion routines, integrate ETS.</h3>
+
+<p>
+Currently, several different inkjet drivers implement their own, very
+similar but slightly differing error diffusion methods.  This has caused
+severe code bloat as well as tempting future driver writers to contribute to
+it further.  We want to factor out error diffusion into a common set of
+facilities that drivers can use.  <I>We would like to design
+these facilities so that they can easily interface to the Even-Toned
+Screening algorithms from artofcode (Raph Levien), to the extent that these
+will be Open Source.</I>
+
+<h3>Improve, or generalize, linearization for stochastic threshold data.</h3>
+
+<p>
+The Ghostscript distribution includes a stochastic threshold array.  This
+array has some gamma correction built into it, which works well for some
+output devices and not for others.  We would like to provide a version of
+this array without (or with less) gamma correction.  <I>We have
+original data available from which this could be done fairly easily.</I>
+
+<h3>Change sampled functions to use new interpreted functions.</h3>
+
+<p>
+The PostScript language defines many functions relevant to graphics
+rendering as being implemented by arbitrary PostScript procedures: transfer
+(gamma correction), black generation, undercolor removal, several stages of
+CIE color space and rendering, and color mapping for Separation and DeviceN
+spaces.  Since the graphics library can't call PostScript procedures,
+Ghostscript currently samples these procedures at a fixed number of points
+and interpolates linearly between the samples.  As of Ghostscript 6.20, the
+library can interpret a restricted subset of PostScript procedures directly
+(basically those that only use arithmetic and comparisons: no loops,
+sub-procedures, or data structures).  Changing the rendering functions to
+use this approach when possible would greatly improve output quality when
+the functions are very non-linear (which we have actually seen in practice).
+<I>This should only be done if the function is, in fact,
+severely non-linear, since interpreting the function definition will almost
+always be much slower than interpolating in the table.</I>
+
+<h3>Add optional cubic interpolation to RenderTable and other table lookup.</h3>
+
+<p>
+Currently, if a CIE rendering dictionary uses a lookup table for the final
+step, Ghostscript always interpolates linearly between the entries.  Cubic
+interpolation should be supported as an option.  A cubic interpolation
+option is also needed for general table-lookup Functions.
+
+<h3>Add better (SVG-like) alpha channel and compositing to library.</h3>
+
+<p>
+Ghostscript has partial support for alpha channel and for alpha and RasterOp
+compositing.  There is some architectural support for general compositing,
+but it postdates the RasterOp implementation, and most of the RasterOp code
+doesn't use it.  We expect that the more extensive compositing and alpha
+capabilities of SVG will find their way into PDF (and probably PostScript as
+well) in the course of 2000 and 2001, and we will need to implement them.
+
+<h1><a name="Other_topics"></a>Other topics</h1>
+
+<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3>
 
 <p>
 There is a project to create a GNU implementation of the OPENStep API, which
@@ -81,6 +365,27 @@ Display PostScript system with some of the NeXT extensions.  For more
 information, please contact Net-Community &lt;<a
 href="mailto:scottc@net-community.com">scottc@net-community.com</a>&gt;.
 
+<h3>Job Server implementation.</h3>
+
+<p>
+For full Adobe PostScript compatibility, Ghostscript needs a real "job
+server" to encapsulate the execution of PostScript files. 
+<I>See the section on "Job Execution Environment" in the PostScript
+Language Reference Manual for details.</I>
+
+<h3>Fully re-entrant code.</h3>
+
+<p>
+Currently, neither the PostScript interpreter nor the graphics library is
+fully re-entrant (no writable globals).  Making them fully re-entrant would
+make Ghostscript usable in multi-threaded environments, and more easily
+usable in embedded environments.  Note that this is necessary, but far from
+sufficient, for Ghostscript to allow simultaneous execution of a single
+Ghostscript interpreter instance by multiple threads: that is probably
+permanently out of the question.  <I>Almost all drivers, including all of
+Aladdin's own drivers, are already fully re-entrant; making the remaining
+ones re-entrant should really be up to the driver author.</I>
+
 <!-- [2.0 end contents] ==================================================== -->
 
 <!-- [3.0 begin visible trailer] =========================================== -->