123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627 |
- <!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.2 2002/02/01 05:31:25 raph 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 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 <<a
- href="mailto:scottc@net-community.com">scottc@net-community.com</a>>.
- <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 © 2000 Aladdin Enterprises. All rights
- reserved.</small>
- <p>
- <small>This file is part of AFPL Ghostscript. See the
- <a href="Public.htm">Aladdin Free Public License</a> (the "License") for
- full details of the terms of using, copying, modifying, and redistributing
- AFPL Ghostscript.</small>
- <p>
- <small>Ghostscript version 7.04, 31 January 2002
- <!-- [3.0 end visible trailer] ============================================= -->
- </body>
- </html>
|