13ff48bf5SDavid du Colombier<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 23ff48bf5SDavid du Colombier<html> 33ff48bf5SDavid du Colombier<head> 43ff48bf5SDavid du Colombier<title>Ghostscript projects</title> 5*593dc095SDavid du Colombier<!-- $Id: Projects.htm,v 1.67 2005/10/20 19:46:23 ray Exp $ --> 63ff48bf5SDavid du Colombier<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"> 73ff48bf5SDavid du Colombier</head> 83ff48bf5SDavid du Colombier 93ff48bf5SDavid du Colombier<body> 103ff48bf5SDavid du Colombier<!-- [1.0 begin visible header] ============================================ --> 113ff48bf5SDavid du Colombier 123ff48bf5SDavid du Colombier<!-- [1.1 begin headline] ================================================== --> 133ff48bf5SDavid du Colombier 143ff48bf5SDavid du Colombier<h1>Ghostscript projects seeking developers</h1> 153ff48bf5SDavid du Colombier 163ff48bf5SDavid du Colombier<!-- [1.1 end headline] ==================================================== --> 173ff48bf5SDavid du Colombier 183ff48bf5SDavid du Colombier<!-- [1.2 begin table of contents] ========================================= --> 193ff48bf5SDavid du Colombier 203ff48bf5SDavid du Colombier<h2>Table of contents</h2> 213ff48bf5SDavid du Colombier 223ff48bf5SDavid du Colombier<ul> 233ff48bf5SDavid du Colombier<li><a href="#Platforms">Platforms</a> 243ff48bf5SDavid du Colombier<li><a href="#Driver_architecture">Driver architecture</a> 253ff48bf5SDavid du Colombier<li><a href="#Specific_drivers">Specific drivers</a> 263ff48bf5SDavid du Colombier<li><a href="#Graphics_functionality">Graphics functionality</a> 273ff48bf5SDavid du Colombier<li><a href="#Performance">Performance</a> 283ff48bf5SDavid du Colombier<li><a href="#Other_functionality">Other functionality</a> 293ff48bf5SDavid du Colombier<li><a href="#Other_implementation">Implementation improvements</a> 303ff48bf5SDavid du Colombier</ul> 313ff48bf5SDavid du Colombier 323ff48bf5SDavid du Colombier<!-- [1.2 end table of contents] =========================================== --> 333ff48bf5SDavid du Colombier 343ff48bf5SDavid du Colombier<!-- [1.3 begin hint] ====================================================== --> 353ff48bf5SDavid du Colombier 363ff48bf5SDavid du Colombier<p>For other information, see the <a href="Readme.htm">Ghostscript 373ff48bf5SDavid du Colombieroverview</a>. 383ff48bf5SDavid du Colombier 393ff48bf5SDavid du Colombier<!-- [1.3 end hint] ======================================================== --> 403ff48bf5SDavid du Colombier 413ff48bf5SDavid du Colombier<hr> 423ff48bf5SDavid du Colombier 433ff48bf5SDavid du Colombier<!-- [1.0 end visible header] ============================================== --> 443ff48bf5SDavid du Colombier 453ff48bf5SDavid du Colombier<!-- [2.0 begin contents] ================================================== --> 463ff48bf5SDavid du Colombier 473ff48bf5SDavid du Colombier<p> 483ff48bf5SDavid du ColombierThere are many projects that would improve Ghostscript and that we would 493ff48bf5SDavid du Colombierlike to do, but for which we don't have enough resources. If you would like 503ff48bf5SDavid du Colombierto take responsibility for any of these projects, please <a 513ff48bf5SDavid du Colombierhref="mailto:raph@artofcode.com">contact us</a>. Additional comments on 523ff48bf5SDavid du Colombierimplementation approaches or project goals are in <I>italic type like 533ff48bf5SDavid du Colombierthis</I>. 543ff48bf5SDavid du Colombier 553ff48bf5SDavid du Colombier<h2><a name="Platforms"></a>Additional platforms</h2> 563ff48bf5SDavid du Colombier 573ff48bf5SDavid du Colombier<h3>DOS, Windows and OS/2 builds using gcc.</h3> 583ff48bf5SDavid du Colombier 593ff48bf5SDavid du Colombier<p> 603ff48bf5SDavid du ColombierWe would like Ghostscript to work with the free <b><tt>emx/gcc</tt></b> and 613ff48bf5SDavid du Colombier<b><tt>rsx</tt></b> libraries, to provide an alternative DOS, Windows 623ff48bf5SDavid du Colombier95/98/NT, and OS/2 implementation that requires no proprietary, commercial 633ff48bf5SDavid du Colombiercompilers. We think Ghostscript's existing OS/2 makefile already includes 643ff48bf5SDavid du Colombiermost of what is needed. If someone is willing to do the work, we will be 653ff48bf5SDavid du Colombierhappy to include this in our list of supported platforms and to distribute 663ff48bf5SDavid du Colombierthe makefiles. 673ff48bf5SDavid du Colombier 683ff48bf5SDavid du Colombier<h3>Windows driver using Ghostscript as a language monitor.</h3> 693ff48bf5SDavid du Colombier 703ff48bf5SDavid du Colombier<p> 713ff48bf5SDavid du ColombierMS Windows has a "language monitor" capability which would allow Ghostscript 723ff48bf5SDavid du Colombierto be invoked seamlessly to process input files in any language Ghostscript 733ff48bf5SDavid du Colombiercould handle (currently PostScript and PDF) and for any printer for which 743ff48bf5SDavid du ColombierGhostscript had a driver. Doing this properly would require integrating 753ff48bf5SDavid du ColombierGhostscript with Windows' "Add Printer" dialog, and would also require 763ff48bf5SDavid du Colombiercreating a PPD for Ghostscript. <I>Russell Lang's RedMon program provides 773ff48bf5SDavid du Colombiersome, but not all, of this capability.</I> 783ff48bf5SDavid du Colombier 793ff48bf5SDavid du Colombier<h3>Netscape browser plug-in.</h3> 803ff48bf5SDavid du Colombier 813ff48bf5SDavid du Colombier<p> 823ff48bf5SDavid du ColombierCurrently, Ghostscript can work as a "helper application" for the Netscape 833ff48bf5SDavid du Colombierbrowser, but not as a plug-in; the latter would integrate it more closely 843ff48bf5SDavid du Colombierwith the browser. We aren't sure what doing this would involve; we've also 853ff48bf5SDavid du Colombierheard by rumor that it's already been done. 863ff48bf5SDavid du Colombier 873ff48bf5SDavid du Colombier<h3>Ghostscript as an Active-X COM Object.</h3> 883ff48bf5SDavid du Colombier 893ff48bf5SDavid du Colombier<p> 903ff48bf5SDavid du ColombierIn order to integrate Ghostscript into XMetaL and other applications it 913ff48bf5SDavid du Colombierwould be convenient for Ghostscript to be distributed as a COM object 923ff48bf5SDavid du Colombieralong with the current gswin32.exe, gswin32c.exe and gsdll32.dll files. 933ff48bf5SDavid du Colombier 94*593dc095SDavid du Colombier<h3>Visual Trace window for X.</h3> 95*593dc095SDavid du Colombier 96*593dc095SDavid du Colombier<p> 97*593dc095SDavid du ColombierCurrently Ghostscript implements Visual Trace window for Windows only 98*593dc095SDavid du Colombier(see <I>wdtrace.c</I>). An implementation for X would be useful. 99*593dc095SDavid du Colombier 100*593dc095SDavid du Colombier<p> 1013ff48bf5SDavid du Colombier<hr> 1023ff48bf5SDavid du Colombier 1033ff48bf5SDavid du Colombier<h2><a name="Driver_architecture"></a>Driver Architecture</h2> 1043ff48bf5SDavid du Colombier 1053ff48bf5SDavid du Colombier<h3>Improved multi-threaded rendering support.</h3> 1063ff48bf5SDavid du Colombier 1073ff48bf5SDavid du Colombier<p> 1083ff48bf5SDavid du ColombierCurrently, drivers can be written so that converting PostScript to a list of 1093ff48bf5SDavid du Colombiergraphical objects can run in one thread, and rasterizing the objects can run 1103ff48bf5SDavid du Colombierin another thread. However, drivers must be written specially if they are 1113ff48bf5SDavid du Colombiergoing to do this. We would like to change the architecture so that any 1123ff48bf5SDavid du Colombierdriver can work this way. We would also like to support dual-threaded 1133ff48bf5SDavid du Colombieroperation for drivers that produce high-level output, such as the PDF 1143ff48bf5SDavid du Colombierwriter. <I>Doing this would require separating banding from 1153ff48bf5SDavid du Colombierthe multithreaded logic. Also, currently each thread has its own allocation 1163ff48bf5SDavid du Colombierpool: this is unnecessary in the normal case, since Ghostscript now supports 1173ff48bf5SDavid du Colombierproperly locked access to the C heap, but embedded systems still need to use 1183ff48bf5SDavid du Colombiera fixed-size area for the rasterizing thread. With a locked, shared 1193ff48bf5SDavid du Colombierallocator, the rasterizing thread could use the full set of band list 1203ff48bf5SDavid du Colombierfunctions; with a fixed-size area and a separate allocator, only a subset is 1213ff48bf5SDavid du Colombieravailable, as is the case now for dual-threaded drivers. 1223ff48bf5SDavid du Colombier</I> 1233ff48bf5SDavid du Colombier 1243ff48bf5SDavid du Colombier<h3>Dynamic run-time loadable devices.</h3> 1253ff48bf5SDavid du Colombier 1263ff48bf5SDavid du Colombier<p> 1273ff48bf5SDavid du ColombierCurrently, drivers must be linked into the executable. We would like to be 1283ff48bf5SDavid du Colombierable to load drivers dynamically. Doing this requires defining a 1293ff48bf5SDavid du Colombierplatform-independent API (presumably extending the current gp_* APIs) that 1303ff48bf5SDavid du Colombierwould work at least on Linux, vendor Unix, MS Windows, and Macintosh. Unix 1313ff48bf5SDavid du Colombiersystems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formats 1323ff48bf5SDavid du Colombiershould both be supported. <I>Consider the Netscape plug-in 1333ff48bf5SDavid du Colombierarchitecture.</I> 1343ff48bf5SDavid du Colombier 1353ff48bf5SDavid du Colombier<h3>Moving 'setpagedevice' into C.</h3> 1363ff48bf5SDavid du Colombier 1373ff48bf5SDavid du Colombier<p> 1383ff48bf5SDavid du ColombierThe PostScript 'setpagedevice' function implements matching of media and 1393ff48bf5SDavid du Colombierpage size requests to available media, page orientation, and paper handling 1403ff48bf5SDavid du Colombier(duplex, etc.) Currently it is implemented in PostScript code, which means 1413ff48bf5SDavid du Colombierit is not available for use with other input languages. (It is available 1423ff48bf5SDavid du Colombierfor PDF, which Ghostscript implements on top of PostScript, but not for the 1433ff48bf5SDavid du Colombiernot-yet-freely-available PCL interpreters that use the Ghostscript library, 1443ff48bf5SDavid du Colombieror for possible future SVG or similar interpreters). We would like to move 1453ff48bf5SDavid du Colombierthis function into C. <I>The device driver will be required to 1463ff48bf5SDavid du Colombiersend page parameters up to PostScript to be stored in a resource. To be 1473ff48bf5SDavid du Colombierincluded in this project are handling policy implementations in the device 1483ff48bf5SDavid du Colombierdrivers. DeferredMediaSelection should also be implemented.</I> 1493ff48bf5SDavid du Colombier 1503ff48bf5SDavid du Colombier<h3>Adding 'tee' for output to multiple devices.</h3> 1513ff48bf5SDavid du Colombier 1523ff48bf5SDavid du Colombier<p> 1533ff48bf5SDavid du ColombierIn a few cases, it would be desirable to provide a 'tee' capability for 1543ff48bf5SDavid du Colombierdrivers: specifically, for generating small, low-resolution 'thumbnail' 1553ff48bf5SDavid du Colombierimages concurrently with other output. <I>Probably the 1563ff48bf5SDavid du Colombiersimplest way to do this is to generate a band list and then process it 1573ff48bf5SDavid du Colombiertwice. This is not completely trivial, since the band list does include 1583ff48bf5SDavid du Colombierdevice resolution information and scaling would be required for some 1593ff48bf5SDavid du Colombierconstructs.</I> 1603ff48bf5SDavid du Colombier 1613ff48bf5SDavid du Colombier<h3><b><tt>OutputDevice</tt></b> resource category</h3> 1623ff48bf5SDavid du Colombier 1633ff48bf5SDavid du Colombier<p> 1643ff48bf5SDavid du ColombierEach available output device should provide an instance of the 1653ff48bf5SDavid du Colombier<b><tt>OutputDevice</tt></b> resource category, which gives the available 1663ff48bf5SDavid du Colombierpage sizes, resolutions, media classes, process color models, and other 1673ff48bf5SDavid du Colombierinformation about the device. <I>This would replace the current 1683ff48bf5SDavid du Colombiernon-standard use of a 4-element <b><tt>PageSize</tt></b> in the 1693ff48bf5SDavid du Colombier<b><tt>InputAttributes</tt></b> entry of the page device dictionary.</I> 1703ff48bf5SDavid du Colombier 1713ff48bf5SDavid du Colombier<h3>Removing the limit on the length of OutputFile.</h3> 1723ff48bf5SDavid du Colombier 1733ff48bf5SDavid du Colombier<p> 1743ff48bf5SDavid du ColombierCurrently, the maximum length of the <b><tt>OutputFile</tt></b> parameter is 1753ff48bf5SDavid du Colombiera compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>. This is 1763ff48bf5SDavid du Colombierappropriate for ordinary file names, since this constant is the platform's 1773ff48bf5SDavid du Colombierlimit on the length of a file name. However, if <b><tt>OutputFile</tt></b> 1783ff48bf5SDavid du Colombieris a pipe, the length should not be limited in this way. <I>This is 1793ff48bf5SDavid du Colombierprobably a small project: it requires allocating the file name dynamically, 1803ff48bf5SDavid du Colombierand freeing it in the finalization routine that gets called when a driver 1813ff48bf5SDavid du Colombierinstance is freed.</I>. 1823ff48bf5SDavid du Colombier 1833ff48bf5SDavid du Colombier<h2><a name="Specific_drivers"></a>Specific drivers</h2> 1843ff48bf5SDavid du Colombier 1853ff48bf5SDavid du Colombier<h3>PrintGear and PPA output drivers.</h3> 1863ff48bf5SDavid du Colombier 1873ff48bf5SDavid du Colombier<p> 1883ff48bf5SDavid du ColombierWe would like to provide (Adobe) PrintGear and (H-P) PPA output drivers for 1893ff48bf5SDavid du ColombierGhostscript, but the specifications for these protocols are not published. 1903ff48bf5SDavid du ColombierIf you can provide them to us without violating any agreements, please let 1913ff48bf5SDavid du Colombierus know. (Some work has already been done on reverse-engineering these 1923ff48bf5SDavid du Colombierprotocols, but we don't have references to it.) 1933ff48bf5SDavid du Colombier 1943ff48bf5SDavid du Colombier<h3>Improve 'pswrite' up to the level of 'pdfwrite'.</h3> 1953ff48bf5SDavid du Colombier 1963ff48bf5SDavid du Colombier<p> 1973ff48bf5SDavid du ColombierWe would like to improve the high-level PostScript-writing 1983ff48bf5SDavid du Colombier<b><tt>pswrite</tt></b> driver to bring it up to parity with the PDF-writing 1993ff48bf5SDavid du Colombierdriver (including the many improvements in the latter being implemented in 2003ff48bf5SDavid du ColombierGhostscript 7.xx). Specifically, we want it to write text as text rather 2013ff48bf5SDavid du Colombierthan bitmaps, and to consistently write images in their original high-level 2023ff48bf5SDavid du Colombierform. <I>We have already started to factor out code that 2033ff48bf5SDavid du Colombiershould be common to these two drivers, specifically for writing embedded 2043ff48bf5SDavid du Colombierfonts and compressed data streams.</I> 2053ff48bf5SDavid du Colombier 2063ff48bf5SDavid du Colombier<p> 2073ff48bf5SDavid du ColombierThere is one small part of this project that would be especially valuable 2083ff48bf5SDavid du Colombierand could be done independently (although it might have to be partly or 2093ff48bf5SDavid du Colombierentirely redone later): compressing images. Currently the driver only 2103ff48bf5SDavid du Colombiercompresses character bitmaps, and doesn't compress other images at all. 2113ff48bf5SDavid du Colombier<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deep 2123ff48bf5SDavid du Colombierimages, and plane-separated <b><tt>LZWEncode</tt></b> compression for color 213*593dc095SDavid du Colombierimages. When generating LL3 PS, the 2143ff48bf5SDavid du Colombier<b><tt>Flate</tt></b> compression will work better than miGIF. It may be 2153ff48bf5SDavid du Colombierworth trying several methods on each image and use the one that works best.</I> 2163ff48bf5SDavid du Colombier 2173ff48bf5SDavid du Colombier<h3>High level graphics and text for PCL 5 and PCL XL drivers.</h3> 2183ff48bf5SDavid du Colombier 2193ff48bf5SDavid du Colombier<p> 2203ff48bf5SDavid du ColombierCurrently, the PCL 5 drivers produce only bitmaps; the PCL XL driver 2213ff48bf5SDavid du Colombierproduces high-level graphics and sometimes high-level images, but low-level 2223ff48bf5SDavid du Colombiertext. We would like to improve these drivers to produce higher-level, 2233ff48bf5SDavid du Colombiersmaller output. <I>This was a very low-priority project; it has become more 2243ff48bf5SDavid du Colombierimportant now that H-P's laser printers are shipping with less memory.</I> 2253ff48bf5SDavid du Colombier 2263ff48bf5SDavid du Colombier<h3>Improved high level GDI driver for Windows.</h3> 2273ff48bf5SDavid du Colombier 2283ff48bf5SDavid du Colombier<p> 2293ff48bf5SDavid du ColombierWe would like a "GDI driver" for MS Windows that would implement more 2303ff48bf5SDavid du Colombierhigher-level constructs (specifically for text). <I> The 2313ff48bf5SDavid du Colombier<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some of 2323ff48bf5SDavid du Colombierthis. Some of the the 'xfont' support code for MS Windows should be useful. 2333ff48bf5SDavid du ColombierWe were frustrated in the past because the GDI calls for getting font sizes 2343ff48bf5SDavid du Colombierand metrics consistently returned incorrect information and provided no way 2353ff48bf5SDavid du Colombierto get the correct information; perhaps this has been fixed in 32-bit 2363ff48bf5SDavid du ColombierWindows. We believe that H-P, Russell Lang, and perhaps others are working 2373ff48bf5SDavid du Colombierin this area, but we can always use more help.</I> 2383ff48bf5SDavid du Colombier 2393ff48bf5SDavid du Colombier<h3>PDF thumbnail generation.</h3> 2403ff48bf5SDavid du Colombier 2413ff48bf5SDavid du Colombier<p> 2423ff48bf5SDavid du ColombierThe PDF writer needs to be able to generate thumbnails (small previews). We 2433ff48bf5SDavid du Colombiermight do this through the 'tee' capability mentioned above. However, we 2443ff48bf5SDavid du Colombiercurrently prefer the idea of implementing a completely separate program to 2453ff48bf5SDavid du Colombieradd thumbnails to an arbitrary, existing PDF file: this would allow 2463ff48bf5SDavid du ColombierGhostscript to add thumbnails to PDF files generated by other programs. 2473ff48bf5SDavid du Colombier<I>Much of the code needed to do this has already been written 2483ff48bf5SDavid du Colombierfor Ghostscript's PDF linearizer: see 2493ff48bf5SDavid du Colombier<b><tt>lib/pdfwrite.ps</tt></b>. A user has implemented this as well, 2503ff48bf5SDavid du Colombierusing a separate program that calls Ghostscript: see 2513ff48bf5SDavid du Colombier<a href="http://www.uni-giessen.de/~g029/eurotex99/oberdiek/"> 2523ff48bf5SDavid du Colombierhttp://www.uni-giessen.de/~g029/eurotex99/oberdiek/</a>. 2533ff48bf5SDavid du Colombier</I> 2543ff48bf5SDavid du Colombier 2553ff48bf5SDavid du Colombier<h3>Consolidate inkjet drivers into a single family.</h3> 2563ff48bf5SDavid du Colombier 2573ff48bf5SDavid du Colombier<p> 2583ff48bf5SDavid du ColombierIn addition to factoring out the error diffusion code as described below, we 2593ff48bf5SDavid du Colombierwould like to see another attempt at reducing the enormous volume of code 2603ff48bf5SDavid du Colombierfor color inkjet drivers. There are three sets of drivers (gdevcdj.c, 2613ff48bf5SDavid du Colombiergdevstc.c, gdevupd.c) with much overlapping functionality. The latter two 2623ff48bf5SDavid du Colombierdriver families make good attempts at factoring out things like head 2633ff48bf5SDavid du Colombiergeometry and canned control strings, but we think this problem deserves 2643ff48bf5SDavid du Colombieranother pass, especially in the hope of consolidating these drivers into a 2653ff48bf5SDavid du Colombiersingle family. 2663ff48bf5SDavid du Colombier 2673ff48bf5SDavid du Colombier<h3>Download glyph bitmaps (with glyph decaching notification).</h3> 2683ff48bf5SDavid du Colombier 2693ff48bf5SDavid du Colombier<p> 2703ff48bf5SDavid du ColombierSee below under "Notification for glyph decaching." 2713ff48bf5SDavid du Colombier 2723ff48bf5SDavid du Colombier<h3>Preserve compression when writing PDF images.</h3> 2733ff48bf5SDavid du Colombier 2743ff48bf5SDavid du Colombier<p> 2753ff48bf5SDavid du ColombierCurrently, all images are decompressed by the interpreter before being 2763ff48bf5SDavid du Colombierpassed to the graphics library; the PDF writer may then compress them again. 2773ff48bf5SDavid du ColombierOrdinarily, this only slows things down a little, but in the case of 2783ff48bf5SDavid du ColombierDCT-encoded images that are being DCT-encoded in the output, image 2793ff48bf5SDavid du Colombierdegradation may occur. Ideally, the implementation should be smart enough 2803ff48bf5SDavid du Colombierto not decode and re-encode the image. However, making this work properly 2813ff48bf5SDavid du Colombieris difficult. <I>This would probably involve extending the library APIs for 2823ff48bf5SDavid du Colombierimages so that they could pass a stream, possibly including filters, instead 2833ff48bf5SDavid du Colombierof the (fully decoded) data rows.</I> 2843ff48bf5SDavid du Colombier 285*593dc095SDavid du Colombier<h3>Emit warnings when producing PDF output.</h3> 286*593dc095SDavid du Colombier 287*593dc095SDavid du Colombier<p> 288*593dc095SDavid du ColombierCurrently, the PDF writer has no way to emit warnings. Users would like to 289*593dc095SDavid du Colombiersee warnings when fonts cannot be embedded (this is actually required when 290*593dc095SDavid du Colombierthe value of CannotEmbedFontPolicy is set to /Warning), and for some other 291*593dc095SDavid du Colombierquestionable situations like non-existent Dests (Feature request 292*593dc095SDavid du Colombier<a href="http://bugs.ghostscript.com/show_bug.cgi?id=480853" 293*593dc095SDavid du Colombierclass="offsite">#480853</a>). 294*593dc095SDavid du ColombierProbably the right way to handle this is with a pseudo device parameter 295*593dc095SDavid du Colombiercalled "Warnings" that is a list of strings: the pdfwrite driver would add 296*593dc095SDavid du Colombierstrings to this list, and the ps2pdf script (lib/gs_pdfwr.ps) would read 297*593dc095SDavid du Colombierthem out, print them, and reset them at the end of each page. 298*593dc095SDavid du Colombier 2993ff48bf5SDavid du Colombier<hr> 3003ff48bf5SDavid du Colombier 3013ff48bf5SDavid du Colombier<h2><a name="Graphics_functionality"></a>Graphics functionality</h2> 3023ff48bf5SDavid du Colombier 3033ff48bf5SDavid du Colombier<h3>Support for 64-bit colors on 64-bit platforms.</h3> 3043ff48bf5SDavid du Colombier 3053ff48bf5SDavid du Colombier<p> 3063ff48bf5SDavid du ColombierCurrently, the library supports a maximum of 32 bits of data per pixel; we 3073ff48bf5SDavid du Colombierwould like to raise this limit to 64 bits on systems where the 'long' data 3083ff48bf5SDavid du Colombiertype is 64 bits wide. <I>The <b><tt>gx_color_index</tt></b> 3093ff48bf5SDavid du Colombiertype is already defined as 'long', but there are many places where the type 3103ff48bf5SDavid du Colombier<b><tt>bits32</tt></b> is used for pixel values; there is a 32-bit 3113ff48bf5SDavid du Colombierstored-image "device", but there is no 64-bit device; a few algorithms and 3123ff48bf5SDavid du Colombiertables have knowledge of the 32-bit width built into them, only because the 3133ff48bf5SDavid du ColombierC preprocessor doesn't have any kind of loop or repetition 3143ff48bf5SDavid du Colombiercapability.</I> 3153ff48bf5SDavid du Colombier 3163ff48bf5SDavid du Colombier<h3>In-RIP trapping.</h3> 3173ff48bf5SDavid du Colombier 3183ff48bf5SDavid du Colombier<p> 3193ff48bf5SDavid du ColombierThe PostScript specification includes an option for the interpreter to 3203ff48bf5SDavid du Colombierimplement trapping (adjustments of object boundaries to prevent visual 3213ff48bf5SDavid du Colombieranomalies caused by slight misregistration of different ink layers): we 3223ff48bf5SDavid du Colombierwould like to implement this. <I>This is a complex and 3233ff48bf5SDavid du Colombierdifficult area; even many Adobe RIPs don't do it.</I> 3243ff48bf5SDavid du Colombier 325*593dc095SDavid du Colombier<h3>Improve the font grid fitting and antialiasing.</h3> 3263ff48bf5SDavid du Colombier 3273ff48bf5SDavid du Colombier<p> 328*593dc095SDavid du ColombierGhostscript includes a reduced True Type bytecode interpreter branched from FreeType 1. 329*593dc095SDavid du ColombierIt performs a grid fitting for True Type glyphs except ones involving 330*593dc095SDavid du Colombierinstructions patented by Apple. A wanted improvement is to implement 331*593dc095SDavid du Colombiera stem recognition algorithm similar to Free Type autohinting. 332*593dc095SDavid du ColombierIt also would help to poorly designed Type 1 fonts, which have misplaced or missed hints. 333*593dc095SDavid du Colombier 334*593dc095SDavid du Colombier<p> 335*593dc095SDavid du ColombierAnother useful improvement is to implement a font antialiasing with 336*593dc095SDavid du Colombier<b><tt>TextAlphaBits</tt></b> other than 1,2,4. 3373ff48bf5SDavid du Colombier 3383ff48bf5SDavid du Colombier<h3>ICC profile support for output.</h3> 3393ff48bf5SDavid du Colombier 3403ff48bf5SDavid du Colombier<p> 3413ff48bf5SDavid du ColombierGhostscript 7.00 and later supports ICCBased color spaces of PDF 3423ff48bf5SDavid du Colombierusing the icclib package from 3433ff48bf5SDavid du Colombier<a href="http://web.access.net.au/argyll/color.html "> 3443ff48bf5SDavid du Colombierhttp://web.access.net.au/argyll/color.html</a> 3453ff48bf5SDavid du Colombierbut there is no facility to use ICC output (printer) profiles that 3463ff48bf5SDavid du Colombiermay be embedded in the PDF. Also it would be useful for PostScript 3473ff48bf5SDavid du Colombierto be able to directly use a specific Intent from ICC profile to 3483ff48bf5SDavid du Colombierconvert output colors (as CRD's are now used). 3493ff48bf5SDavid du Colombier<I>The primary difficulty is that the graphics library and PostScript 3503ff48bf5SDavid du Colombieralways use CIE XYZ as the connection space, but ICC profiles may 3513ff48bf5SDavid du Colombieruse CIELAB as the connection space, requiring conversion for use 3523ff48bf5SDavid du Colombierwith the graphics library. </I> 3533ff48bf5SDavid du Colombier 3543ff48bf5SDavid du Colombier<h3>Making halftones into "objects" and adding new types.</h3> 3553ff48bf5SDavid du Colombier 3563ff48bf5SDavid du Colombier<p> 3573ff48bf5SDavid du ColombierCurrently, knowledge of the specific data formats and algorithms for 3583ff48bf5SDavid du Colombierhalftoning permeates too many places in the library. We would like 3593ff48bf5SDavid du Colombierhalftoning to be more "object oriented" (using virtual procedures) so that 3603ff48bf5SDavid du Colombierwe could support other halftoning methods such as direct use of threshold 3613ff48bf5SDavid du Colombierarrays, or the double-rectangle approach added in newer PostScript versions. 3623ff48bf5SDavid du Colombier<I>Threshold arrays take much less space than the current 3633ff48bf5SDavid du Colombierrepresentation, generally at the expense of longer rendering time for 3643ff48bf5SDavid du Colombierblack-and-white images; double-rectangle representation would give us a 3653ff48bf5SDavid du Colombierbetter implementation of AccurateScreens. We might want store both 3663ff48bf5SDavid du Colombierthreshold arrays and the current representation.</I> 3673ff48bf5SDavid du Colombier 3683ff48bf5SDavid du Colombier<h3>Factor out error diffusion routines, integrate ETS.</h3> 3693ff48bf5SDavid du Colombier 3703ff48bf5SDavid du Colombier<p> 3713ff48bf5SDavid du ColombierCurrently, several different inkjet drivers implement their own, very 3723ff48bf5SDavid du Colombiersimilar but slightly differing error diffusion methods. This has caused 3733ff48bf5SDavid du Colombiersevere code bloat as well as tempting future driver writers to contribute to 3743ff48bf5SDavid du Colombierit further. We want to factor out error diffusion into a common set of 3753ff48bf5SDavid du Colombierfacilities that drivers can use. <I>We would like to design 3763ff48bf5SDavid du Colombierthese facilities so that they can easily interface to the Even-Toned 3773ff48bf5SDavid du ColombierScreening algorithms from artofcode (Raph Levien), to the extent that these 3783ff48bf5SDavid du Colombierwill be Open Source.</I> 3793ff48bf5SDavid du Colombier 3803ff48bf5SDavid du Colombier<h3>Improve, or generalize, linearization for stochastic threshold 3813ff48bf5SDavid du Colombierdata.</h3> 3823ff48bf5SDavid du Colombier 3833ff48bf5SDavid du Colombier<p> 3843ff48bf5SDavid du ColombierThe Ghostscript distribution includes a stochastic threshold array. This 3853ff48bf5SDavid du Colombierarray has some gamma correction built into it, which works well for some 3863ff48bf5SDavid du Colombieroutput devices and not for others. We would like to provide a version of 3873ff48bf5SDavid du Colombierthis array without (or with less) gamma correction. <I>We have 3883ff48bf5SDavid du Colombieroriginal data available from which this could be done fairly easily.</I> 3893ff48bf5SDavid du Colombier 3903ff48bf5SDavid du Colombier<h3>Change sampled functions to use new interpreted functions.</h3> 3913ff48bf5SDavid du Colombier 3923ff48bf5SDavid du Colombier<p> 3933ff48bf5SDavid du ColombierThe PostScript language defines many functions relevant to graphics 3943ff48bf5SDavid du Colombierrendering as being implemented by arbitrary PostScript procedures: transfer 3953ff48bf5SDavid du Colombier(gamma correction), black generation, undercolor removal, several stages of 3963ff48bf5SDavid du ColombierCIE color space and rendering, and color mapping for Separation and DeviceN 3973ff48bf5SDavid du Colombierspaces. Since the graphics library can't call PostScript procedures, 3983ff48bf5SDavid du ColombierGhostscript currently samples these procedures at a fixed number of points 3993ff48bf5SDavid du Colombierand interpolates linearly between the samples. As of Ghostscript 6.20, the 4003ff48bf5SDavid du Colombierlibrary can interpret a restricted subset of PostScript procedures directly 4013ff48bf5SDavid du Colombier(basically those that only use arithmetic and comparisons: no loops, 4023ff48bf5SDavid du Colombiersub-procedures, or data structures). Changing the rendering functions to 4033ff48bf5SDavid du Colombieruse this approach when possible would greatly improve output quality when 4043ff48bf5SDavid du Colombierthe functions are very non-linear (which we have actually seen in practice). 4053ff48bf5SDavid du Colombier<I>This should only be done if the function is, in fact, 4063ff48bf5SDavid du Colombierseverely non-linear, since interpreting the function definition will almost 4073ff48bf5SDavid du Colombieralways be much slower than interpolating in the table.</I> 4083ff48bf5SDavid du Colombier 409*593dc095SDavid du Colombier<h3>Replace PostScript procedures with Function objects.</h3> 410*593dc095SDavid du Colombier 411*593dc095SDavid du Colombier<p> 412*593dc095SDavid du ColombierCurrently, there is a lot of tiresome code for doing callbacks with 413*593dc095SDavid du Colombiercontinuations for loading the caches that hold sampled values for the 414*593dc095SDavid du Colombierprocedures listed under "Change sampled functions ..." above. For the 415*593dc095SDavid du ColombierSeparation and DeviceN tint transform functions, and only for these, 416*593dc095SDavid du ColombierPostScript code associated with the setcolorspace operator actually converts 417*593dc095SDavid du Colombierthe PostScript procedure to a Function object -- to a FunctionType 4 418*593dc095SDavid du Colombier(PostScript subset) Function if possible, or to a FunctionType 0 (sampled) 419*593dc095SDavid du ColombierFunction if not. This approach should be used for all the other sampled 420*593dc095SDavid du Colombierfunctions. Doing this would reduce the amount of C code significantly, 421*593dc095SDavid du Colombierwhile only increasing PostScript code slightly. 422*593dc095SDavid du Colombier 423*593dc095SDavid du Colombier<p> 424*593dc095SDavid du ColombierThis change would require touching (and slightly changing) all PostScript 425*593dc095SDavid du Colombieroperators that currently do such callbacks: for example, rather than a 426*593dc095SDavid du Colombiersetblackgeneration operator that takes a PostScript procedure as its 427*593dc095SDavid du Colombieroperand, we would have a .setblackgeneration operator that takes as operands 428*593dc095SDavid du Colombierboth the PostScript procedure (so that currentblackgeneration can return it) 429*593dc095SDavid du Colombier*and* a Function derived from it (which will actually be used when loading 430*593dc095SDavid du Colombierthe cache, or for sampling directly if desired). 431*593dc095SDavid du Colombier 432*593dc095SDavid du Colombier<p> 433*593dc095SDavid du ColombierIn some cases, this approach has a non-negligible space cost. If the 434*593dc095SDavid du ColombierPostScript procedure cannot be represented as a FunctionType 4 Function, it 435*593dc095SDavid du Colombiermust be sampled and represented as a FunctionType 0 Function. Then the BG / 436*593dc095SDavid du ColombierUCR / transfer / ... cache will essentially just hold a copy of the Function 437*593dc095SDavid du Colombierdata. While it is likely that this situation will be rare in practice, it 438*593dc095SDavid du Colombiermight be worth looking into changing the internal representation of these 439*593dc095SDavid du Colombiercaches so that they were the same as the representation of a FunctionType 0 440*593dc095SDavid du ColombierFunction with a particular choice of parameters. Then the PostScript code 441*593dc095SDavid du Colombierthat called .buildsampledfunction when necessary could arrange the 442*593dc095SDavid du Colombierparameters to have the same values as the internal representation of the 443*593dc095SDavid du Colombiercache, and the cache could use the Function data directly. This is probably 444*593dc095SDavid du Colombiernot worth the trouble. 445*593dc095SDavid du Colombier 4463ff48bf5SDavid du Colombier<h3>Add optional cubic interpolation to RenderTable and other table 4473ff48bf5SDavid du Colombierlookup.</h3> 4483ff48bf5SDavid du Colombier 4493ff48bf5SDavid du Colombier<p> 4503ff48bf5SDavid du ColombierCurrently, if a CIE rendering dictionary uses a lookup table for the final 4513ff48bf5SDavid du Colombierstep, Ghostscript always interpolates linearly between the entries. Cubic 4523ff48bf5SDavid du Colombierinterpolation should be supported as an option. A cubic interpolation 4533ff48bf5SDavid du Colombieroption is also needed for general table-lookup Functions. 4543ff48bf5SDavid du Colombier 4553ff48bf5SDavid du Colombier<h3>Add better (SVG-like) alpha channel and compositing to library.</h3> 4563ff48bf5SDavid du Colombier 4573ff48bf5SDavid du Colombier<p> 4583ff48bf5SDavid du ColombierGhostscript has partial support for alpha channel and for alpha and RasterOp 4593ff48bf5SDavid du Colombiercompositing. There is some architectural support for general compositing, 4603ff48bf5SDavid du Colombierbut it postdates the RasterOp implementation, and most of the RasterOp code 4613ff48bf5SDavid du Colombierdoesn't use it. We expect that the more extensive compositing and alpha 4623ff48bf5SDavid du Colombiercapabilities of SVG will find their way into PDF (and probably PostScript as 4633ff48bf5SDavid du Colombierwell) in the course of 2000 and 2001, and we will need to implement them. 4643ff48bf5SDavid du Colombier 4653ff48bf5SDavid du Colombier<hr> 4663ff48bf5SDavid du Colombier 4673ff48bf5SDavid du Colombier<h2><a name="Performance"></a>Performance</h2> 4683ff48bf5SDavid du Colombier 4693ff48bf5SDavid du Colombier<h3>Change band list logic to defer halftoning until rendering.</h3> 4703ff48bf5SDavid du Colombier 4713ff48bf5SDavid du Colombier<p> 4723ff48bf5SDavid du ColombierCurrently, when Ghostscript uses a band list, it does halftoning before 4733ff48bf5SDavid du Colombierbanding. It should do halftoning after banding: this produces smaller band 4743ff48bf5SDavid du Colombierlists and shifts more work to the rasterizer (which is good because the 4753ff48bf5SDavid du Colombierrasterizer can be multi-threaded internally for higher performance on 4763ff48bf5SDavid du Colombiermultiprocessors: see the next topic.) 4773ff48bf5SDavid du Colombier 4783ff48bf5SDavid du Colombier<h3>Reduce redundant data for smoothed banded images.</h3> 4793ff48bf5SDavid du Colombier 4803ff48bf5SDavid du Colombier<p> 4813ff48bf5SDavid du ColombierWhen smoothed ("interpolated") images are written in the band list, extra 4823ff48bf5SDavid du Colombierrows must be written above and below each band in order to provide the data 4833ff48bf5SDavid du Colombierfor interpolation. Currently, the number of such rows is computed very 4843ff48bf5SDavid du Colombierconservatively; instead, the final interpolation algorithm should be 4853ff48bf5SDavid du Colombierconsulted to provide the correct value. <i>This is a small task.</i> 4863ff48bf5SDavid du Colombier 4873ff48bf5SDavid du Colombier<h3>Multi-threaded rasterizing</h3> 4883ff48bf5SDavid du Colombier 4893ff48bf5SDavid du Colombier<p> 4903ff48bf5SDavid du ColombierFor high-resolution devices, rasterization dominates execution time. On 4913ff48bf5SDavid du Colombiermultiprocessor systems, Ghostscript can do tasks in parallel: 4923ff48bf5SDavid du Colombier 4933ff48bf5SDavid du Colombier<ul> 4943ff48bf5SDavid du Colombier 4953ff48bf5SDavid du Colombier<li>Rasterize multiple bands simultaneously; 4963ff48bf5SDavid du Colombier 4973ff48bf5SDavid du Colombier<li>Rasterize multiple color planes of a single band simultaneously (if a 4983ff48bf5SDavid du Colombierplanar representation is being used); 4993ff48bf5SDavid du Colombier 5003ff48bf5SDavid du Colombier<li>For some computation-intensive tasks like smoothing images or filling 5013ff48bf5SDavid du Colombierlarge regions, partition the task (possibly buffering more data to allow 5023ff48bf5SDavid du Colombierlarger-grain partitioning) and execute several partitions simultaneously. 5033ff48bf5SDavid du Colombier 5043ff48bf5SDavid du Colombier</ul> 5053ff48bf5SDavid du Colombier 5063ff48bf5SDavid du Colombier<p> 5073ff48bf5SDavid du ColombierWe would want these facilities implemented so that no conditional 5083ff48bf5SDavid du Colombiercompilation was involved: on uniprocessor systems, the locking API would 5093ff48bf5SDavid du Colombiersimply have a vacuous implementation. 5103ff48bf5SDavid du Colombier 5113ff48bf5SDavid du Colombier<h3>Notification for glyph decaching.</h3> 5123ff48bf5SDavid du Colombier 5133ff48bf5SDavid du Colombier<p> 5143ff48bf5SDavid du ColombierCurrently, drivers can't do a very good job of downloading rendered 5153ff48bf5SDavid du Colombiercharacter bitmaps to the device they manage, because they can't find out 5163ff48bf5SDavid du Colombierwhen a bitmap is being deleted from Ghostscript's cache and therefore will 5173ff48bf5SDavid du Colombiernever be referenced again. Here is a sketch of how we would add this 5183ff48bf5SDavid du Colombiercapability to the graphics library: 5193ff48bf5SDavid du Colombier 5203ff48bf5SDavid du Colombier<ul> 5213ff48bf5SDavid du Colombier 5223ff48bf5SDavid du Colombier<li>The driver would implement the <b><tt>text_begin</tt></b> call, simply 5233ff48bf5SDavid du Colombierto get access to a <b><tt>gs_imager_state</tt></b> that references the 5243ff48bf5SDavid du Colombierrendered character cache. (The driver could always simply call the default 5253ff48bf5SDavid du Colombierimplementation of <b><tt>text_begin</tt></b>.) 5263ff48bf5SDavid du Colombier 5273ff48bf5SDavid du Colombier<li>In the <b><tt>text_begin</tt></b> procedure, the driver would call 5283ff48bf5SDavid du Colombier 5293ff48bf5SDavid du Colombier<blockquote><pre> 5303ff48bf5SDavid du Colombiergs_glyph_decache_register(imager_state, notify_proc, proc_data) 5313ff48bf5SDavid du Colombier</pre></blockquote> 5323ff48bf5SDavid du Colombier 5333ff48bf5SDavid du Colombier<p> 5343ff48bf5SDavid du Colombierwhere <b><tt>proc_data</tt></b> was, or pointed to a structure that 5353ff48bf5SDavid du Colombierincluded, a pointer to the driver. 5363ff48bf5SDavid du Colombier 5373ff48bf5SDavid du Colombier<li><b><tt>gs_glyph_decache_register</tt></b> would use the general 5383ff48bf5SDavid du Colombiernotification mechanism defined in <b><tt>gsnotify.h</tt></b> to call 5393ff48bf5SDavid du Colombier 5403ff48bf5SDavid du Colombier<blockquote><pre> 5413ff48bf5SDavid du Colombiernotify_proc(proc_data, pchar_data) 5423ff48bf5SDavid du Colombier</pre></blockquote> 5433ff48bf5SDavid du Colombier 5443ff48bf5SDavid du Colombier<p> 5453ff48bf5SDavid du Colombierwhenever a bitmap was removed from the character cache. 5463ff48bf5SDavid du Colombier<b><tt>pchar_data</tt></b> would point to some identification of the 5473ff48bf5SDavid du Colombiercharacter; perhaps just the bitmap ID, but possibly a 5483ff48bf5SDavid du Colombier<b><tt>gx_cached_bits_common</tt></b> or even a <b><tt>cached_char</tt></b>. 5493ff48bf5SDavid du Colombier 5503ff48bf5SDavid du Colombier<li>The <b><tt>char_cache</tt></b> structure would be need an additional 5513ff48bf5SDavid du Colombiermember, a <b><tt>gs_notify_list_t</tt></b>. It would also need to add 5523ff48bf5SDavid du Colombierfinalization so that when it was freed, it would notify and unregister all 5533ff48bf5SDavid du Colombierclients, using <b><tt>gs_notify_all(list, NULL)</tt></b> and then 5543ff48bf5SDavid du Colombier<b><tt>gs_notify_release</tt></b>. 5553ff48bf5SDavid du Colombier 5563ff48bf5SDavid du Colombier</ul> 5573ff48bf5SDavid du Colombier 5583ff48bf5SDavid du Colombier<p> 5593ff48bf5SDavid du Colombier<I>This facility was requested by the Display Ghostscript project, but it 5603ff48bf5SDavid du Colombiercould also be used to improve the output of the PCL XL driver and possibly 5613ff48bf5SDavid du Colombierthe X and PCL5 drivers.</I> 5623ff48bf5SDavid du Colombier 5633ff48bf5SDavid du Colombier<hr> 5643ff48bf5SDavid du Colombier 5653ff48bf5SDavid du Colombier<h2><a name="Other_functionality"></a>Other functionality</h2> 5663ff48bf5SDavid du Colombier 5673ff48bf5SDavid du Colombier<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3> 5683ff48bf5SDavid du Colombier 5693ff48bf5SDavid du Colombier<p> 5703ff48bf5SDavid du ColombierThere is a project to create a GNU implementation of the OPENStep API, which 5713ff48bf5SDavid du Colombierinvolves extending Ghostscript to provide the full functionality of Adobe's 5723ff48bf5SDavid du ColombierDisplay PostScript system with some of the NeXT extensions. For more 5733ff48bf5SDavid du Colombierinformation, please contact Net-Community <<a 5743ff48bf5SDavid du Colombierhref="mailto:scottc@net-community.com">scottc@net-community.com</a>>. 5753ff48bf5SDavid du Colombier 5763ff48bf5SDavid du Colombier<h3>Job Server implementation.</h3> 5773ff48bf5SDavid du Colombier 5783ff48bf5SDavid du Colombier<p> 5793ff48bf5SDavid du ColombierFor full Adobe PostScript compatibility, Ghostscript needs a real "job 5803ff48bf5SDavid du Colombierserver" to encapsulate the execution of PostScript files. 5813ff48bf5SDavid du Colombier<I>See the section on "Job Execution Environment" in the PostScript 5823ff48bf5SDavid du ColombierLanguage Reference Manual for details.</I> 5833ff48bf5SDavid du Colombier 5843ff48bf5SDavid du Colombier<h3>SVG (XML Structured Vector Graphics) interpreter.</h3> 5853ff48bf5SDavid du Colombier 5863ff48bf5SDavid du Colombier<p> 5873ff48bf5SDavid du ColombierGhostscript could be adapted with some work to read SVG. This would be an 5883ff48bf5SDavid du Colombierinteresting and challenging project because SVG's graphics model would 5893ff48bf5SDavid du Colombierrequire extending the library (see above). <I>If SVG turns out to be an 5903ff48bf5SDavid du Colombierimportant standard, it is important that there be a good free implementation 5913ff48bf5SDavid du Colombierof it.</I> 5923ff48bf5SDavid du Colombier 5933ff48bf5SDavid du Colombier<h3><b><tt>%font%</tt></b> and other IODevices.</h3> 5943ff48bf5SDavid du Colombier 5953ff48bf5SDavid du Colombier<p> 5963ff48bf5SDavid du ColombierCurrently, the <b><tt>%font%</tt></b> IODevice is not implemented. We would 5973ff48bf5SDavid du Colombierlike to see this implemented using a general framework for implementing 5983ff48bf5SDavid du ColombierIODevices (%xxxx%) entirely in PostScript, in an "object oriented" manner 5993ff48bf5SDavid du Colombiervery similiar to the way Resource categories are implemented. An IODevice 6003ff48bf5SDavid du Colombierwould be implemented as a dictionary with the following keys, whose values 6013ff48bf5SDavid du Colombierwould be procedures that implemented the corresponding operation: 6023ff48bf5SDavid du Colombier 6033ff48bf5SDavid du Colombier<blockquote><pre> 6043ff48bf5SDavid du Colombier/File 6053ff48bf5SDavid du Colombier/DeleteFile 6063ff48bf5SDavid du Colombier/RenameFile 6073ff48bf5SDavid du Colombier/Status 6083ff48bf5SDavid du Colombier/FileNameForAll 6093ff48bf5SDavid du Colombier/GetDevParams 6103ff48bf5SDavid du Colombier/PutDevParams 6113ff48bf5SDavid du Colombier</pre></blockquote> 6123ff48bf5SDavid du Colombier 6133ff48bf5SDavid du Colombier<p> 6143ff48bf5SDavid du ColombierThere would only be global IODevices, no local ones; the dictionary keeping 6153ff48bf5SDavid du Colombiertrack of them would be stored in global VM. 6163ff48bf5SDavid du Colombier 6173ff48bf5SDavid du Colombier<p> 6183ff48bf5SDavid du Colombier<I>This is an obscure feature that matters only because some PostScript code 6193ff48bf5SDavid du Colombieruses <b><tt>filenameforall</tt></b> with this IODevice, rather than 6203ff48bf5SDavid du Colombier<b><tt>filenameforall</tt></b> with the <b><tt>/Font</tt></b> Resource 6213ff48bf5SDavid du Colombiercategory, to enumerate available fonts.</I> 6223ff48bf5SDavid du Colombier 6233ff48bf5SDavid du Colombier<h3>Repairing damaged or EOL-converted PDF files.</h3> 6243ff48bf5SDavid du Colombier 6253ff48bf5SDavid du Colombier<p> 6263ff48bf5SDavid du ColombierAdobe Acrobat Reader can scan a PDF file that has had its end-of-lines 6273ff48bf5SDavid du Colombierconverted by careless users transferring the file across operating systems 6283ff48bf5SDavid du Colombieras text rather than binary across, and reconstruct the cross-reference table 6293ff48bf5SDavid du Colombierwhich the PDF interpreter requires. This only works if the file has no 6303ff48bf5SDavid du Colombierbinary data in it, which with PDF 1.3 is rarely the case. However, users 6313ff48bf5SDavid du Colombieroccasionally receive PDF files that have been damaged in this way, and it 6323ff48bf5SDavid du Colombiermight be useful to have a program that can repair them. <I>We think this 6333ff48bf5SDavid du Colombiershould probably be done as a separate program, possibly in PostScript, 6343ff48bf5SDavid du Colombiersimilar to Ghostscript's PDF linearizer.</I> 6353ff48bf5SDavid du Colombier 6363ff48bf5SDavid du Colombier<h2><a name="Other_implementation"></a>Implementation improvements</h2> 6373ff48bf5SDavid du Colombier 6383ff48bf5SDavid du Colombier<h3>Fully re-entrant code.</h3> 6393ff48bf5SDavid du Colombier 6403ff48bf5SDavid du Colombier<p> 6413ff48bf5SDavid du ColombierCurrently, neither the PostScript interpreter nor the graphics library is 6423ff48bf5SDavid du Colombierfully re-entrant (no writable globals). Making them fully re-entrant would 6433ff48bf5SDavid du Colombiermake Ghostscript usable in multi-threaded environments, and more easily 6443ff48bf5SDavid du Colombierusable in embedded environments. Note that this is necessary, but far from 6453ff48bf5SDavid du Colombiersufficient, for Ghostscript to allow simultaneous execution of a single 6463ff48bf5SDavid du ColombierGhostscript interpreter instance by multiple threads: that is probably 6473ff48bf5SDavid du Colombierpermanently out of the question. <I>Almost all drivers, including all of 6483ff48bf5SDavid du Colombierthe drivers in devs.mak which are maintained as part of the main Ghostscript 6493ff48bf5SDavid du Colombiercode, are already fully re-entrant; making the remaining ones re-entrant 6503ff48bf5SDavid du Colombiershould really be up to the driver author.</I> 6513ff48bf5SDavid du Colombier 6523ff48bf5SDavid du Colombier<h3>Ghostscript has no %ram% device.</h3> 6533ff48bf5SDavid du Colombier 654*593dc095SDavid du Colombier<p> 6553ff48bf5SDavid du ColombierThe %ram% device is documented in PS Supplement 3010 and 3011 dated August 30, 1999. 6563ff48bf5SDavid du ColombierThis is probably not a major impediment to portability, but it would be handy. 6573ff48bf5SDavid du Colombier<p><I> 6583ff48bf5SDavid du ColombierOn Unix, the suggested implementation would be to create a subdirectory 6593ff48bf5SDavid du Colombierof the temporary directory (usually /tmp), with the name chosen and the 6603ff48bf5SDavid du Colombierdirectory created in such a way as to avoid /tmp races and similar 6613ff48bf5SDavid du Colombierproblems. Ghostscript should delete the subdirectory when it exits. 6623ff48bf5SDavid du Colombier</I> 6633ff48bf5SDavid du Colombier 6643ff48bf5SDavid du Colombier<!-- [2.0 end contents] ==================================================== --> 6653ff48bf5SDavid du Colombier 6663ff48bf5SDavid du Colombier<!-- [3.0 begin visible trailer] =========================================== --> 6673ff48bf5SDavid du Colombier<hr> 6683ff48bf5SDavid du Colombier 6693ff48bf5SDavid du Colombier<p> 6703ff48bf5SDavid du Colombier<small>Copyright © 2000 Aladdin Enterprises. All rights 6713ff48bf5SDavid du Colombierreserved.</small> 6723ff48bf5SDavid du Colombier 6733ff48bf5SDavid du Colombier<p> 674*593dc095SDavid du ColombierThis software is provided AS-IS with no warranty, either express or 675*593dc095SDavid du Colombierimplied. 676*593dc095SDavid du Colombier 677*593dc095SDavid du ColombierThis software is distributed under license and may not be copied, 678*593dc095SDavid du Colombiermodified or distributed except as expressly authorized under the terms 679*593dc095SDavid du Colombierof the license contained in the file LICENSE in this distribution. 680*593dc095SDavid du Colombier 681*593dc095SDavid du ColombierFor more information about licensing, please refer to 682*593dc095SDavid du Colombierhttp://www.ghostscript.com/licensing/. For information on 683*593dc095SDavid du Colombiercommercial licensing, go to http://www.artifex.com/licensing/ or 684*593dc095SDavid du Colombiercontact Artifex Software, Inc., 101 Lucas Valley Road #110, 685*593dc095SDavid du ColombierSan Rafael, CA 94903, U.S.A., +1(415)492-9861. 6863ff48bf5SDavid du Colombier 6873ff48bf5SDavid du Colombier<p> 688*593dc095SDavid du Colombier<small>Ghostscript version 8.53, 20 October 2005 6893ff48bf5SDavid du Colombier 6903ff48bf5SDavid du Colombier<!-- [3.0 end visible trailer] ============================================= --> 6913ff48bf5SDavid du Colombier 6923ff48bf5SDavid du Colombier</body> 6933ff48bf5SDavid du Colombier</html> 694