<!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.67 2005/10/20 19:46:23 ray 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">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>. <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, 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. <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. <h3>Ghostscript as an Active-X COM Object.</h3> <p>In order to integrate Ghostscript into XMetaL and other applications itwould be convenient for Ghostscript to be distributed as a COM objectalong with the current gswin32.exe, gswin32c.exe and gsdll32.dll files. <h3>Visual Trace window for X.</h3> <p>Currently Ghostscript implements Visual Trace window for Windows only(see <I>wdtrace.c</I>). An implementation for X would be useful.  <p><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 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 7.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.  When generating LL3 PS, the<b><tt>Flate</tt></b> compression will work better than miGIF. It may beworth 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 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> <h3>Emit warnings when producing PDF output.</h3> <p>Currently, the PDF writer has no way to emit warnings.  Users would like tosee warnings when fonts cannot be embedded (this is actually required whenthe value of CannotEmbedFontPolicy is set to /Warning), and for some otherquestionable situations like non-existent Dests (Feature request<a href="http://bugs.ghostscript.com/show_bug.cgi?id=480853"class="offsite">#480853</a>).Probably the right way to handle this is with a pseudo device parametercalled "Warnings" that is a list of strings: the pdfwrite driver would addstrings to this list, and the ps2pdf script (lib/gs_pdfwr.ps) would readthem out, print them, and reset them at the end of each page. <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; 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>Improve the font grid fitting and antialiasing.</h3> <p>Ghostscript includes a reduced True Type bytecode interpreter branched from FreeType 1.It performs a grid fitting for True Type glyphs except ones involvinginstructions patented by Apple. A wanted improvement is to implementa stem recognition algorithm similar to Free Type autohinting.It also would help to poorly designed Type 1 fonts, which have misplaced or missed hints.  <p>Another useful improvement is to implement a font antialiasing with <b><tt>TextAlphaBits</tt></b> other than 1,2,4. <h3>ICC profile support for output.</h3> <p>Ghostscript 7.00 and later supports ICCBased color spaces of PDFusing 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 thatmay be embedded in the PDF. Also it would be useful for PostScriptto be able to directly use a specific Intent from ICC profile toconvert output colors (as CRD's are now used).<I>The primary difficulty is that the graphics library and PostScriptalways use CIE XYZ as the connection space, but ICC profiles mayuse CIELAB as the connection space, requiring conversion for usewith the graphics library. </I> <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 thresholddata.</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>Replace PostScript procedures with Function objects.</h3> <p>Currently, there is a lot of tiresome code for doing callbacks withcontinuations for loading the caches that hold sampled values for theprocedures listed under "Change sampled functions ..." above.  For theSeparation and DeviceN tint transform functions, and only for these,PostScript code associated with the setcolorspace operator actually convertsthe PostScript procedure to a Function object -- to a FunctionType 4(PostScript subset) Function if possible, or to a FunctionType 0 (sampled)Function if not.  This approach should be used for all the other sampledfunctions.  Doing this would reduce the amount of C code significantly,while only increasing PostScript code slightly. <p>This change would require touching (and slightly changing) all PostScriptoperators that currently do such callbacks: for example, rather than asetblackgeneration operator that takes a PostScript procedure as itsoperand, we would have a .setblackgeneration operator that takes as operandsboth the PostScript procedure (so that currentblackgeneration can return it)*and* a Function derived from it (which will actually be used when loadingthe cache, or for sampling directly if desired). <p>In some cases, this approach has a non-negligible space cost.  If thePostScript procedure cannot be represented as a FunctionType 4 Function, itmust be sampled and represented as a FunctionType 0 Function.  Then the BG /UCR / transfer / ... cache will essentially just hold a copy of the Functiondata.  While it is likely that this situation will be rare in practice, itmight be worth looking into changing the internal representation of thesecaches so that they were the same as the representation of a FunctionType 0Function with a particular choice of parameters.  Then the PostScript codethat called .buildsampledfunction when necessary could arrange theparameters to have the same values as the internal representation of thecache, and the cache could use the Function data directly.  This is probablynot worth the trouble. <h3>Add optional cubic interpolation to RenderTable and other tablelookup.</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. <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 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 filling

Lines 1–500 of 693. Load more