summaryrefslogtreecommitdiff
path: root/Master/xemtex/doc/ghostscript/Projects.htm
diff options
context:
space:
mode:
Diffstat (limited to 'Master/xemtex/doc/ghostscript/Projects.htm')
-rw-r--r--Master/xemtex/doc/ghostscript/Projects.htm629
1 files changed, 0 insertions, 629 deletions
diff --git a/Master/xemtex/doc/ghostscript/Projects.htm b/Master/xemtex/doc/ghostscript/Projects.htm
deleted file mode 100644
index 3ee7f5cad5f..00000000000
--- a/Master/xemtex/doc/ghostscript/Projects.htm
+++ /dev/null
@@ -1,629 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<title>Ghostscript projects</title>
-<!-- $Id: Projects.htm,v 1.33.2.11.2.6 2003/05/17 14:39:00 giles Exp $ -->
-<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style">
-</head>
-
-<body>
-<!-- [1.0 begin visible header] ============================================ -->
-
-<!-- [1.1 begin headline] ================================================== -->
-
-<h1>Ghostscript projects seeking developers</h1>
-
-<!-- [1.1 end headline] ==================================================== -->
-
-<!-- [1.2 begin table of contents] ========================================= -->
-
-<h2>Table of contents</h2>
-
-<ul>
-<li><a href="#Platforms">Platforms</a>
-<li><a href="#Driver_architecture">Driver architecture</a>
-<li><a href="#Specific_drivers">Specific drivers</a>
-<li><a href="#Graphics_functionality">Graphics functionality</a>
-<li><a href="#Performance">Performance</a>
-<li><a href="#Other_functionality">Other functionality</a>
-<li><a href="#Other_implementation">Implementation improvements</a>
-</ul>
-
-<!-- [1.2 end table of contents] =========================================== -->
-
-<!-- [1.3 begin hint] ====================================================== -->
-
-<p>For other information, see the <a href="Readme.htm">Ghostscript
-overview</a>.
-
-<!-- [1.3 end hint] ======================================================== -->
-
-<hr>
-
-<!-- [1.0 end visible header] ============================================== -->
-
-<!-- [2.0 begin contents] ================================================== -->
-
-<p>
-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:raph@artofcode.com">contact us</a>. Additional comments on
-implementation approaches or project goals are in <I>italic type like
-this</I>.
-
-<h2><a name="Platforms"></a>Additional platforms</h2>
-
-<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
-95/98/NT, and OS/2 implementation that requires no proprietary, commercial
-compilers. We think Ghostscript's existing OS/2 makefile already includes
-most of what is needed. If someone is willing to do the work, we will be
-happy to include this in our list of supported platforms and to distribute
-the makefiles.
-
-<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>
-
-<h3>Netscape browser plug-in.</h3>
-
-<p>
-Currently, Ghostscript can work as a "helper application" for the Netscape
-browser, but not as a plug-in; the latter would integrate it more closely
-with the browser. We aren't sure what doing this would involve; we've also
-heard by rumor that it's already been done.
-
-<h3>Ghostscript as an Active-X COM Object.</h3>
-
-<p>
-In order to integrate Ghostscript into XMetaL and other applications it
-would be convenient for Ghostscript to be distributed as a COM object
-along with the current gswin32.exe, gswin32c.exe and gsdll32.dll files.
-
-<hr>
-
-<h2><a name="Driver_architecture"></a>Driver 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 GNU/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>
-
-<h3><b><tt>OutputDevice</tt></b> resource category</h3>
-
-<p>
-Each available output device should provide an instance of the
-<b><tt>OutputDevice</tt></b> resource category, which gives the available
-page sizes, resolutions, media classes, process color models, and other
-information about the device. <I>This would replace the current
-non-standard use of a 4-element <b><tt>PageSize</tt></b> in the
-<b><tt>InputAttributes</tt></b> entry of the page device dictionary.</I>
-
-<h3>Removing the limit on the length of OutputFile.</h3>
-
-<p>
-Currently, the maximum length of the <b><tt>OutputFile</tt></b> parameter is
-a compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>. This is
-appropriate for ordinary file names, since this constant is the platform's
-limit on the length of a file name. However, if <b><tt>OutputFile</tt></b>
-is a pipe, the length should not be limited in this way. <I>This is
-probably a small project: it requires allocating the file name dynamically,
-and freeing it in the finalization routine that gets called when a driver
-instance is freed.</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
-Ghostscript, but the specifications for these protocols are not published.
-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.)
-
-<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 7.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>
-
-<p>
-There is one small part of this project that would be especially valuable
-and could be done independently (although it might have to be partly or
-entirely redone later): compressing images. Currently the driver only
-compresses character bitmaps, and doesn't compress other images at all.
-<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deep
-images, and plane-separated <b><tt>LZWEncode</tt></b> compression for color
-images, using the <b><tt>miGIF</tt></b> algorithms that are believed to be
-free of the Welch patent for the latter. When generating LL3 PS, the
-<b><tt>Flate</tt></b> compression will work better than miGIF. It may be
-worth trying several methods on each image and use the one that works best.</I>
-
-<h3>High level graphics and text 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. <I>This was a very low-priority project; it has become more
-important now that H-P's laser printers are shipping with less memory.</I>
-
-<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.
-
-<h3>Download glyph bitmaps (with glyph decaching notification).</h3>
-
-<p>
-See below under "Notification for glyph decaching."
-
-<h3>Preserve compression when writing PDF images.</h3>
-
-<p>
-Currently, all images are decompressed by the interpreter before being
-passed to the graphics library; the PDF writer may then compress them again.
-Ordinarily, this only slows things down a little, but in the case of
-DCT-encoded images that are being DCT-encoded in the output, image
-degradation may occur. Ideally, the implementation should be smart enough
-to not decode and re-encode the image. However, making this work properly
-is difficult. <I>This would probably involve extending the library APIs for
-images so that they could pass a stream, possibly including filters, instead
-of the (fully decoded) data rows.</I>
-
-<hr>
-
-<h2><a name="Graphics_functionality"></a>Graphics functionality</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 profile support for output.</h3>
-
-<p>
-Ghostscript 7.00 and later supports ICCBased color spaces of PDF
-using the icclib package from
-<a href="http://web.access.net.au/argyll/color.html ">
-http://web.access.net.au/argyll/color.html</a>
-but there is no facility to use ICC output (printer) profiles that
-may be embedded in the PDF. Also it would be useful for PostScript
-to be able to directly use a specific Intent from ICC profile to
-convert output colors (as CRD's are now used).
-<I>The primary difficulty is that the graphics library and PostScript
-always use CIE XYZ as the connection space, but ICC profiles may
-use CIELAB as the connection space, requiring conversion for use
-with the graphics library. </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>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.
-
-<hr>
-
-<h2><a name="Performance"></a>Performance</h2>
-
-<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: see the next topic.)
-
-<h3>Reduce redundant data for smoothed banded images.</h3>
-
-<p>
-When smoothed ("interpolated") images are written in the band list, extra
-rows must be written above and below each band in order to provide the data
-for interpolation. Currently, the number of such rows is computed very
-conservatively; instead, the final interpolation algorithm should be
-consulted to provide the correct value. <i>This is a small task.</i>
-
-<h3>Multi-threaded rasterizing</h3>
-
-<p>
-For high-resolution devices, rasterization dominates execution time. On
-multiprocessor systems, Ghostscript can do tasks in parallel:
-
-<ul>
-
-<li>Rasterize multiple bands simultaneously;
-
-<li>Rasterize multiple color planes of a single band simultaneously (if a
-planar representation is being used);
-
-<li>For some computation-intensive tasks like smoothing images or filling
-large regions, partition the task (possibly buffering more data to allow
-larger-grain partitioning) and execute several partitions simultaneously.
-
-</ul>
-
-<p>
-We would want these facilities implemented so that no conditional
-compilation was involved: on uniprocessor systems, the locking API would
-simply have a vacuous implementation.
-
-<h3>Notification for glyph decaching.</h3>
-
-<p>
-Currently, drivers can't do a very good job of downloading rendered
-character bitmaps to the device they manage, because they can't find out
-when a bitmap is being deleted from Ghostscript's cache and therefore will
-never be referenced again. Here is a sketch of how we would add this
-capability to the graphics library:
-
-<ul>
-
-<li>The driver would implement the <b><tt>text_begin</tt></b> call, simply
-to get access to a <b><tt>gs_imager_state</tt></b> that references the
-rendered character cache. (The driver could always simply call the default
-implementation of <b><tt>text_begin</tt></b>.)
-
-<li>In the <b><tt>text_begin</tt></b> procedure, the driver would call
-
-<blockquote><pre>
-gs_glyph_decache_register(imager_state, notify_proc, proc_data)
-</pre></blockquote>
-
-<p>
-where <b><tt>proc_data</tt></b> was, or pointed to a structure that
-included, a pointer to the driver.
-
-<li><b><tt>gs_glyph_decache_register</tt></b> would use the general
-notification mechanism defined in <b><tt>gsnotify.h</tt></b> to call
-
-<blockquote><pre>
-notify_proc(proc_data, pchar_data)
-</pre></blockquote>
-
-<p>
-whenever a bitmap was removed from the character cache.
-<b><tt>pchar_data</tt></b> would point to some identification of the
-character; perhaps just the bitmap ID, but possibly a
-<b><tt>gx_cached_bits_common</tt></b> or even a <b><tt>cached_char</tt></b>.
-
-<li>The <b><tt>char_cache</tt></b> structure would be need an additional
-member, a <b><tt>gs_notify_list_t</tt></b>. It would also need to add
-finalization so that when it was freed, it would notify and unregister all
-clients, using <b><tt>gs_notify_all(list, NULL)</tt></b> and then
-<b><tt>gs_notify_release</tt></b>.
-
-</ul>
-
-<p>
-<I>This facility was requested by the Display Ghostscript project, but it
-could also be used to improve the output of the PCL XL driver and possibly
-the X and PCL5 drivers.</I>
-
-<hr>
-
-<h2><a name="Other_functionality"></a>Other functionality</h2>
-
-<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3>
-
-<p>
-There is a project to create a GNU implementation of the OPENStep API, which
-involves extending Ghostscript to provide the full functionality of Adobe's
-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>SVG (XML Structured Vector Graphics) interpreter.</h3>
-
-<p>
-Ghostscript could be adapted with some work to read SVG. This would be an
-interesting and challenging project because SVG's graphics model would
-require extending the library (see above). <I>If SVG turns out to be an
-important standard, it is important that there be a good free implementation
-of it.</I>
-
-<h3><b><tt>%font%</tt></b> and other IODevices.</h3>
-
-<p>
-Currently, the <b><tt>%font%</tt></b> IODevice is not implemented. We would
-like to see this implemented using a general framework for implementing
-IODevices (%xxxx%) entirely in PostScript, in an "object oriented" manner
-very similiar to the way Resource categories are implemented. An IODevice
-would be implemented as a dictionary with the following keys, whose values
-would be procedures that implemented the corresponding operation:
-
-<blockquote><pre>
-/File
-/DeleteFile
-/RenameFile
-/Status
-/FileNameForAll
-/GetDevParams
-/PutDevParams
-</pre></blockquote>
-
-<p>
-There would only be global IODevices, no local ones; the dictionary keeping
-track of them would be stored in global VM.
-
-<p>
-<I>This is an obscure feature that matters only because some PostScript code
-uses <b><tt>filenameforall</tt></b> with this IODevice, rather than
-<b><tt>filenameforall</tt></b> with the <b><tt>/Font</tt></b> Resource
-category, to enumerate available fonts.</I>
-
-<h3>Repairing damaged or EOL-converted PDF files.</h3>
-
-<p>
-Adobe Acrobat Reader can scan a PDF file that has had its end-of-lines
-converted by careless users transferring the file across operating systems
-as text rather than binary across, and reconstruct the cross-reference table
-which the PDF interpreter requires. This only works if the file has no
-binary data in it, which with PDF 1.3 is rarely the case. However, users
-occasionally receive PDF files that have been damaged in this way, and it
-might be useful to have a program that can repair them. <I>We think this
-should probably be done as a separate program, possibly in PostScript,
-similar to Ghostscript's PDF linearizer.</I>
-
-<h2><a name="Other_implementation"></a>Implementation improvements</h2>
-
-<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
-the drivers in devs.mak which are maintained as part of the main Ghostscript
-code, are already fully re-entrant; making the remaining ones re-entrant
-should really be up to the driver author.</I>
-
-<h3>Ghostscript has no %ram% device.</h3>
-
-The %ram% device is documented in PS Supplement 3010 and 3011 dated August 30, 1999.
-This is probably not a major impediment to portability, but it would be handy.
-<p><I>
-On Unix, the suggested implementation would be to create a subdirectory
-of the temporary directory (usually /tmp), with the name chosen and the
-directory created in such a way as to avoid /tmp races and similar
-problems. Ghostscript should delete the subdirectory when it exits.
-</I>
-
-<!-- [2.0 end contents] ==================================================== -->
-
-<!-- [3.0 begin visible trailer] =========================================== -->
-<hr>
-
-<p>
-<small>Copyright &copy; 2000 Aladdin Enterprises. All rights
-reserved.</small>
-
-<p>
-This software is provided AS-IS with no warranty, either express or
-implied.
-
-This software is distributed under license and may not be copied,
-modified or distributed except as expressly authorized under the terms
-of the license contained in the file LICENSE in this distribution.
-
-<p>
-<small>Ghostscript version 7.07, 17 May 2003
-
-<!-- [3.0 end visible trailer] ============================================= -->
-
-</body>
-</html>