<html><head><title>Ghostscript projects</title><!-- $Id: Projects.htm,v 1.19.2.2 2000/11/28 01:31:25 raph Exp $ --></head> <body><!-- [1.0 begin visible header] ============================================ --> <!-- [1.1 begin headline] ================================================== --> <table width="100%" border="0"><tr><th align="center" bgcolor="#CCCC00"><font size=6>Ghostscript projects seeking developers</font></table> <!-- [1.1 end headline] ==================================================== --> <!-- [1.2 begin table of contents] ========================================= --> <h2>Table of contents</h2> <blockquote><ul><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><ul><li><a href="#Graphics_functionality">Functionality</a><li><a href="#Graphics_performance">Performance</a></ul><li><a href="#Other_topics">Other topics</a><ul><li><a href="#Other_functionality">Functionality</a><li><a href="#Other_implementation">Implementation</a></ul></ul></blockquote> <!-- [1.2 end table of contents] =========================================== --> <!-- [1.3 begin hint] ====================================================== --> <p>For other information, see the <a href="Readme.htm">Ghostscriptoverview</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 wouldlike to do, but for which we don't have enough resources.  If you would liketo take responsibility for any of these projects, please <ahref="mailto:raph@artofcode.com">contact us</a>.  Additional comments onimplementation approaches or project goals are in <I>italic type likethis</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, Windows95/98/NT, and OS/2 implementation that requires no proprietary, commercialcompilers.  We think Ghostscript's existing OS/2 makefile already includesmost of what is needed.  If someone is willing to do the work, we will behappy to include this in our list of supported platforms and to distributethe makefiles.  If interested, please consult <blockquote><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> <h3>Windows driver using Ghostscript as a language monitor.</h3> <p>MS Windows has a "language monitor" capability which would allow Ghostscriptto be invoked seamlessly to process input files in any language Ghostscriptcould handle (currently PostScript and PDF) and for any printer for whichGhostscript had a driver.  Doing this properly would require integratingGhostscript with Windows' "Add Printer" dialog, and would also requirecreating a PPD for Ghostscript.  <I>Russell Lang's RedMon program providessome, but not all, of this capability.</I> <h3>Netscape browser plug-in.</h3> <p>Currently, Ghostscript can work as a "helper application" for the Netscapebrowser, but not as a plug-in; the latter would integrate it more closelywith the browser.  We aren't sure what doing this would involve; we've alsoheard by rumor that it's already been done. <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 ofgraphical objects can run in one thread, and rasterizing the objects can runin another thread.  However, drivers must be written specially if they aregoing to do this.  We would like to change the architecture so that anydriver can work this way.  We would also like to support dual-threadedoperation for drivers that produce high-level output, such as the PDFwriter.  <I>Doing this would require separating banding fromthe multithreaded logic.  Also, currently each thread has its own allocationpool: this is unnecessary in the normal case, since Ghostscript now supportsproperly locked access to the C heap, but embedded systems still need to usea fixed-size area for the rasterizing thread.  With a locked, sharedallocator, the rasterizing thread could use the full set of band listfunctions; with a fixed-size area and a separate allocator, only a subset isavailable, 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 beable to load drivers dynamically.  Doing this requires defining aplatform-independent API (presumably extending the current gp_* APIs) thatwould work at least on Linux, vendor Unix, MS Windows, and Macintosh.  Unixsystems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formatsshould both be supported.  <I>Consider the Netscape plug-inarchitecture.</I> <h3>Moving 'setpagedevice' into C.</h3> <p>The PostScript 'setpagedevice' function implements matching of media andpage size requests to available media, page orientation, and paper handling(duplex, etc.)  Currently it is implemented in PostScript code, which meansit is not available for use with other input languages.  (It is availablefor PDF, which Ghostscript implements on top of PostScript, but not for thenot-yet-freely-available PCL interpreters that use the Ghostscript library,or for possible future SVG or similar interpreters).  We would like to movethis function into C.  <I>The device driver will be required tosend page parameters up to PostScript to be stored in a resource.  To beincluded in this project are handling policy implementations in the devicedrivers.  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 fordrivers: specifically, for generating small, low-resolution 'thumbnail'images concurrently with other output.  <I>Probably thesimplest way to do this is to generate a band list and then process ittwice.  This is not completely trivial, since the band list does includedevice resolution information and scaling would be required for someconstructs.</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 availablepage sizes, resolutions, media classes, process color models, and otherinformation about the device.  <I>This would replace the currentnon-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 isa compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>.  This isappropriate for ordinary file names, since this constant is the platform'slimit 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 isprobably a small project: it requires allocating the file name dynamically,and freeing it in the finalization routine that gets called when a driverinstance 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 forGhostscript, but the specifications for these protocols are not published.If you can provide them to us without violating any agreements, please letus know.  (Some work has already been done on reverse-engineering theseprotocols, 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-writingdriver (including the many improvements in the latter being implemented inGhostscript 6.xx).  Specifically, we want it to write text as text ratherthan bitmaps, and to consistently write images in their original high-levelform.  <I>We have already started to factor out code thatshould be common to these two drivers, specifically for writing embeddedfonts and compressed data streams.</I> <p>There is one small part of this project that would be especially valuableand could be done independently (although it might have to be partly orentirely redone later): compressing images.  Currently the driver onlycompresses character bitmaps, and doesn't compress other images at all.<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deepimages, and plane-separated <b><tt>LZWEncode</tt></b> compression for colorimages, using the <b><tt>miGIF</tt></b> algorithms that are believed to befree of the Welch patent for the latter.  Even better, it should try severalmethods on each image and use the one that works best.</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 thePostScript input.  We have a plan and design for a general DSC-readingcapability, but we need help implementing a full DSC parser and also helpimplementing the specific set of DSC comments that the PDF writer will needto consider.  <I>This set is currently specified very poorly inthe Adobe Acrobat Distiller Parameters documentation: we are working withAdobe to find out the details.</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 driverproduces high-level graphics and sometimes high-level images, but low-leveltext.  We would like to improve these drivers to produce higher-level,smaller output.  <I>This was a very low-priority project; it has become moreimportant 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 morehigher-level constructs (specifically for text).  <I> The<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some ofthis.  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 sizesand metrics consistently returned incorrect information and provided no wayto get the correct information; perhaps this has been fixed in 32-bitWindows.  We believe that H-P, Russell Lang, and perhaps others are workingin 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).  Wemight do this through the 'tee' capability mentioned above.  However, wecurrently prefer the idea of implementing a completely separate program toadd thumbnails to an arbitrary, existing PDF file: this would allowGhostscript to add thumbnails to PDF files generated by other programs.<I>Much of the code needed to do this has already been writtenfor 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, wewould like to see another attempt at reducing the enormous volume of codefor color inkjet drivers.  There are three sets of drivers (gdevcdj.c,gdevstc.c, gdevupd.c) with much overlapping functionality.  The latter twodriver families make good attempts at factoring out things like headgeometry and canned control strings, but we think this problem deservesanother pass, especially in the hope of consolidating these drivers into asingle 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 beingpassed to the graphics library; the PDF writer may then compress them again.Ordinarily, this only slows things down a little, but in the case ofDCT-encoded images that are being DCT-encoded in the output, imagedegradation may occur.  Ideally, the implementation should be smart enoughto not decode and re-encode the image.  However, making this work properlyis difficult.  <I>This would probably involve extending the library APIs forimages so that they could pass a stream, possibly including filters, insteadof the (fully decoded) data rows.</I> <h1><a name="Graphics"></a>Graphics</h1> <h2><a name="Graphics_functionality"></a>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; wewould like to raise this limit to 64 bits on systems where the 'long' datatype 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-bitstored-image "device", but there is no 64-bit device; a few algorithms andtables have knowledge of the 32-bit width built into them, only because theC preprocessor doesn't have any kind of loop or repetitioncapability.</I> <h3>In-RIP trapping.</h3> <p>The PostScript specification includes an option for the interpreter toimplement trapping (adjustments of object boundaries to prevent visualanomalies caused by slight misregistration of different ink layers): wewould like to implement this.  <I>This is a complex anddifficult 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 fontrasterizer into Ghostscript, since the FreeType code is better thanGhostscript's current rasterizers.  We understand that some users in Japanhave done this already, but we don't know if this is a good starting point(the only documentation is in Japanese).  <I>Their work usesGhostscript's 'xfont' interface, which is how Ghostscript interfaces toplatform facilities such as the X and MS Windows font capabilities.  This isa device-level interface and not the best place to do this: we would ratherhave 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 newICCBased color space family; we believe Adobe will add such support toPostScript as well.  We would like to integrate such support into thegraphics library.  One possible approach is to interface with the existingCS/CRD library code so that optimizations and improvements would carry intoICC color as well as CIE color.  However, we've been told that the icclibpackage at <a href="http://web.access.net.au/argyll/color.html">http://web.access.net.au/argyll/color.html</a> is a good one, and ithandles all of its own color mapping.  We would suggest that anyone workingon this project start by examining that package. <h3>Making halftones into "objects" and adding new types.</h3> <p>Currently, knowledge of the specific data formats and algorithms forhalftoning permeates too many places in the library.  We would likehalftoning to be more "object oriented" (using virtual procedures) so thatwe could support other halftoning methods such as direct use of thresholdarrays, or the double-rectangle approach added in newer PostScript versions.<I>Threshold arrays take much less space than the currentrepresentation, generally at the expense of longer rendering time forblack-and-white images; double-rectangle representation would give us abetter implementation of AccurateScreens.  We might want store boththreshold arrays and the current representation.</I> <h3>Factor out error diffusion routines, integrate ETS.</h3> <p>Currently, several different inkjet drivers implement their own, verysimilar but slightly differing error diffusion methods.  This has causedsevere code bloat as well as tempting future driver writers to contribute toit further.  We want to factor out error diffusion into a common set offacilities that drivers can use.  <I>We would like to designthese facilities so that they can easily interface to the Even-TonedScreening algorithms from artofcode (Raph Levien), to the extent that thesewill be Open Source.</I> <h3>Improve, or generalize, linearization for stochastic threshold data.</h3> <p>The Ghostscript distribution includes a stochastic threshold array.  Thisarray has some gamma correction built into it, which works well for someoutput devices and not for others.  We would like to provide a version ofthis array without (or with less) gamma correction.  <I>We haveoriginal 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 graphicsrendering as being implemented by arbitrary PostScript procedures: transfer(gamma correction), black generation, undercolor removal, several stages ofCIE color space and rendering, and color mapping for Separation and DeviceNspaces.  Since the graphics library can't call PostScript procedures,Ghostscript currently samples these procedures at a fixed number of pointsand interpolates linearly between the samples.  As of Ghostscript 6.20, thelibrary 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 touse this approach when possible would greatly improve output quality whenthe 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 almostalways 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 finalstep, Ghostscript always interpolates linearly between the entries.  Cubicinterpolation should be supported as an option.  A cubic interpolationoption 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 RasterOpcompositing.  There is some architectural support for general compositing,but it postdates the RasterOp implementation, and most of the RasterOp codedoesn't use it.  We expect that the more extensive compositing and alphacapabilities of SVG will find their way into PDF (and probably PostScript aswell) in the course of 2000 and 2001, and we will need to implement them. <h2><a name="Graphics_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 beforebanding.  It should do halftoning after banding: this produces smaller bandlists and shifts more work to the rasterizer (which is good because therasterizer can be multi-threaded internally for higher performance onmultiprocessors: see the next topic.) <h3>Reduce redundant data for smoothed banded images.</h3> <p>When smoothed ("interpolated") images are written in the band list, extrarows must be written above and below each band in order to provide the datafor interpolation.  Currently, the number of such rows is computed veryconservatively; instead, the final interpolation algorithm should beconsulted 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.  Onmultiprocessor systems, Ghostscript can do tasks in parallel: <ul> <li>Rasterize multiple bands simultaneously; <li>Rasterize multiple color planes of a single band simultaneously (if aplanar representation is being used); <li>For some computation-intensive tasks like smoothing images or fillinglarge regions, partition the task (possibly buffering more data to allowlarger-grain partitioning) and execute several partitions simultaneously. </ul> <p>We would want these facilities implemented so that no conditionalcompilation was involved: on uniprocessor systems, the locking API wouldsimply have a vacuous implementation. <h3>Notification for glyph decaching.</h3> <p>Currently, drivers can't do a very good job of downloading renderedcharacter bitmaps to the device they manage, because they can't find outwhen a bitmap is being deleted from Ghostscript's cache and therefore willnever be referenced again.  Here is a sketch of how we would add thiscapability to the graphics library: <ul> <li>The driver would implement the <b><tt>text_begin</tt></b> call, simplyto get access to a <b><tt>gs_imager_state</tt></b> that references therendered character cache.  (The driver could always simply call the defaultimplementation 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 thatincluded, a pointer to the driver. <li><b><tt>gs_glyph_decache_register</tt></b> would use the generalnotification 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.

Lines 1–500 of 629. Load more