| 2 |
- |
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
|
2 |
<html>
|
|
|
3 |
<head>
|
|
|
4 |
<title>Ghostscript projects</title>
|
|
|
5 |
<!-- $Id: Projects.htm,v 1.67 2005/10/20 19:46:23 ray Exp $ -->
|
|
|
6 |
<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style">
|
|
|
7 |
</head>
|
|
|
8 |
|
|
|
9 |
<body>
|
|
|
10 |
<!-- [1.0 begin visible header] ============================================ -->
|
|
|
11 |
|
|
|
12 |
<!-- [1.1 begin headline] ================================================== -->
|
|
|
13 |
|
|
|
14 |
<h1>Ghostscript projects seeking developers</h1>
|
|
|
15 |
|
|
|
16 |
<!-- [1.1 end headline] ==================================================== -->
|
|
|
17 |
|
|
|
18 |
<!-- [1.2 begin table of contents] ========================================= -->
|
|
|
19 |
|
|
|
20 |
<h2>Table of contents</h2>
|
|
|
21 |
|
|
|
22 |
<ul>
|
|
|
23 |
<li><a href="#Platforms">Platforms</a>
|
|
|
24 |
<li><a href="#Driver_architecture">Driver architecture</a>
|
|
|
25 |
<li><a href="#Specific_drivers">Specific drivers</a>
|
|
|
26 |
<li><a href="#Graphics_functionality">Graphics functionality</a>
|
|
|
27 |
<li><a href="#Performance">Performance</a>
|
|
|
28 |
<li><a href="#Other_functionality">Other functionality</a>
|
|
|
29 |
<li><a href="#Other_implementation">Implementation improvements</a>
|
|
|
30 |
</ul>
|
|
|
31 |
|
|
|
32 |
<!-- [1.2 end table of contents] =========================================== -->
|
|
|
33 |
|
|
|
34 |
<!-- [1.3 begin hint] ====================================================== -->
|
|
|
35 |
|
|
|
36 |
<p>For other information, see the <a href="Readme.htm">Ghostscript
|
|
|
37 |
overview</a>.
|
|
|
38 |
|
|
|
39 |
<!-- [1.3 end hint] ======================================================== -->
|
|
|
40 |
|
|
|
41 |
<hr>
|
|
|
42 |
|
|
|
43 |
<!-- [1.0 end visible header] ============================================== -->
|
|
|
44 |
|
|
|
45 |
<!-- [2.0 begin contents] ================================================== -->
|
|
|
46 |
|
|
|
47 |
<p>
|
|
|
48 |
There are many projects that would improve Ghostscript and that we would
|
|
|
49 |
like to do, but for which we don't have enough resources. If you would like
|
|
|
50 |
to take responsibility for any of these projects, please <a
|
|
|
51 |
href="mailto:raph@artofcode.com">contact us</a>. Additional comments on
|
|
|
52 |
implementation approaches or project goals are in <I>italic type like
|
|
|
53 |
this</I>.
|
|
|
54 |
|
|
|
55 |
<h2><a name="Platforms"></a>Additional platforms</h2>
|
|
|
56 |
|
|
|
57 |
<h3>DOS, Windows and OS/2 builds using gcc.</h3>
|
|
|
58 |
|
|
|
59 |
<p>
|
|
|
60 |
We would like Ghostscript to work with the free <b><tt>emx/gcc</tt></b> and
|
|
|
61 |
<b><tt>rsx</tt></b> libraries, to provide an alternative DOS, Windows
|
|
|
62 |
95/98/NT, and OS/2 implementation that requires no proprietary, commercial
|
|
|
63 |
compilers. We think Ghostscript's existing OS/2 makefile already includes
|
|
|
64 |
most of what is needed. If someone is willing to do the work, we will be
|
|
|
65 |
happy to include this in our list of supported platforms and to distribute
|
|
|
66 |
the makefiles.
|
|
|
67 |
|
|
|
68 |
<h3>Windows driver using Ghostscript as a language monitor.</h3>
|
|
|
69 |
|
|
|
70 |
<p>
|
|
|
71 |
MS Windows has a "language monitor" capability which would allow Ghostscript
|
|
|
72 |
to be invoked seamlessly to process input files in any language Ghostscript
|
|
|
73 |
could handle (currently PostScript and PDF) and for any printer for which
|
|
|
74 |
Ghostscript had a driver. Doing this properly would require integrating
|
|
|
75 |
Ghostscript with Windows' "Add Printer" dialog, and would also require
|
|
|
76 |
creating a PPD for Ghostscript. <I>Russell Lang's RedMon program provides
|
|
|
77 |
some, but not all, of this capability.</I>
|
|
|
78 |
|
|
|
79 |
<h3>Netscape browser plug-in.</h3>
|
|
|
80 |
|
|
|
81 |
<p>
|
|
|
82 |
Currently, Ghostscript can work as a "helper application" for the Netscape
|
|
|
83 |
browser, but not as a plug-in; the latter would integrate it more closely
|
|
|
84 |
with the browser. We aren't sure what doing this would involve; we've also
|
|
|
85 |
heard by rumor that it's already been done.
|
|
|
86 |
|
|
|
87 |
<h3>Ghostscript as an Active-X COM Object.</h3>
|
|
|
88 |
|
|
|
89 |
<p>
|
|
|
90 |
In order to integrate Ghostscript into XMetaL and other applications it
|
|
|
91 |
would be convenient for Ghostscript to be distributed as a COM object
|
|
|
92 |
along with the current gswin32.exe, gswin32c.exe and gsdll32.dll files.
|
|
|
93 |
|
|
|
94 |
<h3>Visual Trace window for X.</h3>
|
|
|
95 |
|
|
|
96 |
<p>
|
|
|
97 |
Currently Ghostscript implements Visual Trace window for Windows only
|
|
|
98 |
(see <I>wdtrace.c</I>). An implementation for X would be useful.
|
|
|
99 |
|
|
|
100 |
<p>
|
|
|
101 |
<hr>
|
|
|
102 |
|
|
|
103 |
<h2><a name="Driver_architecture"></a>Driver Architecture</h2>
|
|
|
104 |
|
|
|
105 |
<h3>Improved multi-threaded rendering support.</h3>
|
|
|
106 |
|
|
|
107 |
<p>
|
|
|
108 |
Currently, drivers can be written so that converting PostScript to a list of
|
|
|
109 |
graphical objects can run in one thread, and rasterizing the objects can run
|
|
|
110 |
in another thread. However, drivers must be written specially if they are
|
|
|
111 |
going to do this. We would like to change the architecture so that any
|
|
|
112 |
driver can work this way. We would also like to support dual-threaded
|
|
|
113 |
operation for drivers that produce high-level output, such as the PDF
|
|
|
114 |
writer. <I>Doing this would require separating banding from
|
|
|
115 |
the multithreaded logic. Also, currently each thread has its own allocation
|
|
|
116 |
pool: this is unnecessary in the normal case, since Ghostscript now supports
|
|
|
117 |
properly locked access to the C heap, but embedded systems still need to use
|
|
|
118 |
a fixed-size area for the rasterizing thread. With a locked, shared
|
|
|
119 |
allocator, the rasterizing thread could use the full set of band list
|
|
|
120 |
functions; with a fixed-size area and a separate allocator, only a subset is
|
|
|
121 |
available, as is the case now for dual-threaded drivers.
|
|
|
122 |
</I>
|
|
|
123 |
|
|
|
124 |
<h3>Dynamic run-time loadable devices.</h3>
|
|
|
125 |
|
|
|
126 |
<p>
|
|
|
127 |
Currently, drivers must be linked into the executable. We would like to be
|
|
|
128 |
able to load drivers dynamically. Doing this requires defining a
|
|
|
129 |
platform-independent API (presumably extending the current gp_* APIs) that
|
|
|
130 |
would work at least on Linux, vendor Unix, MS Windows, and Macintosh. Unix
|
|
|
131 |
systems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formats
|
|
|
132 |
should both be supported. <I>Consider the Netscape plug-in
|
|
|
133 |
architecture.</I>
|
|
|
134 |
|
|
|
135 |
<h3>Moving 'setpagedevice' into C.</h3>
|
|
|
136 |
|
|
|
137 |
<p>
|
|
|
138 |
The PostScript 'setpagedevice' function implements matching of media and
|
|
|
139 |
page size requests to available media, page orientation, and paper handling
|
|
|
140 |
(duplex, etc.) Currently it is implemented in PostScript code, which means
|
|
|
141 |
it is not available for use with other input languages. (It is available
|
|
|
142 |
for PDF, which Ghostscript implements on top of PostScript, but not for the
|
|
|
143 |
not-yet-freely-available PCL interpreters that use the Ghostscript library,
|
|
|
144 |
or for possible future SVG or similar interpreters). We would like to move
|
|
|
145 |
this function into C. <I>The device driver will be required to
|
|
|
146 |
send page parameters up to PostScript to be stored in a resource. To be
|
|
|
147 |
included in this project are handling policy implementations in the device
|
|
|
148 |
drivers. DeferredMediaSelection should also be implemented.</I>
|
|
|
149 |
|
|
|
150 |
<h3>Adding 'tee' for output to multiple devices.</h3>
|
|
|
151 |
|
|
|
152 |
<p>
|
|
|
153 |
In a few cases, it would be desirable to provide a 'tee' capability for
|
|
|
154 |
drivers: specifically, for generating small, low-resolution 'thumbnail'
|
|
|
155 |
images concurrently with other output. <I>Probably the
|
|
|
156 |
simplest way to do this is to generate a band list and then process it
|
|
|
157 |
twice. This is not completely trivial, since the band list does include
|
|
|
158 |
device resolution information and scaling would be required for some
|
|
|
159 |
constructs.</I>
|
|
|
160 |
|
|
|
161 |
<h3><b><tt>OutputDevice</tt></b> resource category</h3>
|
|
|
162 |
|
|
|
163 |
<p>
|
|
|
164 |
Each available output device should provide an instance of the
|
|
|
165 |
<b><tt>OutputDevice</tt></b> resource category, which gives the available
|
|
|
166 |
page sizes, resolutions, media classes, process color models, and other
|
|
|
167 |
information about the device. <I>This would replace the current
|
|
|
168 |
non-standard use of a 4-element <b><tt>PageSize</tt></b> in the
|
|
|
169 |
<b><tt>InputAttributes</tt></b> entry of the page device dictionary.</I>
|
|
|
170 |
|
|
|
171 |
<h3>Removing the limit on the length of OutputFile.</h3>
|
|
|
172 |
|
|
|
173 |
<p>
|
|
|
174 |
Currently, the maximum length of the <b><tt>OutputFile</tt></b> parameter is
|
|
|
175 |
a compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>. This is
|
|
|
176 |
appropriate for ordinary file names, since this constant is the platform's
|
|
|
177 |
limit on the length of a file name. However, if <b><tt>OutputFile</tt></b>
|
|
|
178 |
is a pipe, the length should not be limited in this way. <I>This is
|
|
|
179 |
probably a small project: it requires allocating the file name dynamically,
|
|
|
180 |
and freeing it in the finalization routine that gets called when a driver
|
|
|
181 |
instance is freed.</I>.
|
|
|
182 |
|
|
|
183 |
<h2><a name="Specific_drivers"></a>Specific drivers</h2>
|
|
|
184 |
|
|
|
185 |
<h3>PrintGear and PPA output drivers.</h3>
|
|
|
186 |
|
|
|
187 |
<p>
|
|
|
188 |
We would like to provide (Adobe) PrintGear and (H-P) PPA output drivers for
|
|
|
189 |
Ghostscript, but the specifications for these protocols are not published.
|
|
|
190 |
If you can provide them to us without violating any agreements, please let
|
|
|
191 |
us know. (Some work has already been done on reverse-engineering these
|
|
|
192 |
protocols, but we don't have references to it.)
|
|
|
193 |
|
|
|
194 |
<h3>Improve 'pswrite' up to the level of 'pdfwrite'.</h3>
|
|
|
195 |
|
|
|
196 |
<p>
|
|
|
197 |
We would like to improve the high-level PostScript-writing
|
|
|
198 |
<b><tt>pswrite</tt></b> driver to bring it up to parity with the PDF-writing
|
|
|
199 |
driver (including the many improvements in the latter being implemented in
|
|
|
200 |
Ghostscript 7.xx). Specifically, we want it to write text as text rather
|
|
|
201 |
than bitmaps, and to consistently write images in their original high-level
|
|
|
202 |
form. <I>We have already started to factor out code that
|
|
|
203 |
should be common to these two drivers, specifically for writing embedded
|
|
|
204 |
fonts and compressed data streams.</I>
|
|
|
205 |
|
|
|
206 |
<p>
|
|
|
207 |
There is one small part of this project that would be especially valuable
|
|
|
208 |
and could be done independently (although it might have to be partly or
|
|
|
209 |
entirely redone later): compressing images. Currently the driver only
|
|
|
210 |
compresses character bitmaps, and doesn't compress other images at all.
|
|
|
211 |
<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deep
|
|
|
212 |
images, and plane-separated <b><tt>LZWEncode</tt></b> compression for color
|
|
|
213 |
images. When generating LL3 PS, the
|
|
|
214 |
<b><tt>Flate</tt></b> compression will work better than miGIF. It may be
|
|
|
215 |
worth trying several methods on each image and use the one that works best.</I>
|
|
|
216 |
|
|
|
217 |
<h3>High level graphics and text for PCL 5 and PCL XL drivers.</h3>
|
|
|
218 |
|
|
|
219 |
<p>
|
|
|
220 |
Currently, the PCL 5 drivers produce only bitmaps; the PCL XL driver
|
|
|
221 |
produces high-level graphics and sometimes high-level images, but low-level
|
|
|
222 |
text. We would like to improve these drivers to produce higher-level,
|
|
|
223 |
smaller output. <I>This was a very low-priority project; it has become more
|
|
|
224 |
important now that H-P's laser printers are shipping with less memory.</I>
|
|
|
225 |
|
|
|
226 |
<h3>Improved high level GDI driver for Windows.</h3>
|
|
|
227 |
|
|
|
228 |
<p>
|
|
|
229 |
We would like a "GDI driver" for MS Windows that would implement more
|
|
|
230 |
higher-level constructs (specifically for text). <I> The
|
|
|
231 |
<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some of
|
|
|
232 |
this. Some of the the 'xfont' support code for MS Windows should be useful.
|
|
|
233 |
We were frustrated in the past because the GDI calls for getting font sizes
|
|
|
234 |
and metrics consistently returned incorrect information and provided no way
|
|
|
235 |
to get the correct information; perhaps this has been fixed in 32-bit
|
|
|
236 |
Windows. We believe that H-P, Russell Lang, and perhaps others are working
|
|
|
237 |
in this area, but we can always use more help.</I>
|
|
|
238 |
|
|
|
239 |
<h3>PDF thumbnail generation.</h3>
|
|
|
240 |
|
|
|
241 |
<p>
|
|
|
242 |
The PDF writer needs to be able to generate thumbnails (small previews). We
|
|
|
243 |
might do this through the 'tee' capability mentioned above. However, we
|
|
|
244 |
currently prefer the idea of implementing a completely separate program to
|
|
|
245 |
add thumbnails to an arbitrary, existing PDF file: this would allow
|
|
|
246 |
Ghostscript to add thumbnails to PDF files generated by other programs.
|
|
|
247 |
<I>Much of the code needed to do this has already been written
|
|
|
248 |
for Ghostscript's PDF linearizer: see
|
|
|
249 |
<b><tt>lib/pdfwrite.ps</tt></b>. A user has implemented this as well,
|
|
|
250 |
using a separate program that calls Ghostscript: see
|
|
|
251 |
<a href="http://www.uni-giessen.de/~g029/eurotex99/oberdiek/">
|
|
|
252 |
http://www.uni-giessen.de/~g029/eurotex99/oberdiek/</a>.
|
|
|
253 |
</I>
|
|
|
254 |
|
|
|
255 |
<h3>Consolidate inkjet drivers into a single family.</h3>
|
|
|
256 |
|
|
|
257 |
<p>
|
|
|
258 |
In addition to factoring out the error diffusion code as described below, we
|
|
|
259 |
would like to see another attempt at reducing the enormous volume of code
|
|
|
260 |
for color inkjet drivers. There are three sets of drivers (gdevcdj.c,
|
|
|
261 |
gdevstc.c, gdevupd.c) with much overlapping functionality. The latter two
|
|
|
262 |
driver families make good attempts at factoring out things like head
|
|
|
263 |
geometry and canned control strings, but we think this problem deserves
|
|
|
264 |
another pass, especially in the hope of consolidating these drivers into a
|
|
|
265 |
single family.
|
|
|
266 |
|
|
|
267 |
<h3>Download glyph bitmaps (with glyph decaching notification).</h3>
|
|
|
268 |
|
|
|
269 |
<p>
|
|
|
270 |
See below under "Notification for glyph decaching."
|
|
|
271 |
|
|
|
272 |
<h3>Preserve compression when writing PDF images.</h3>
|
|
|
273 |
|
|
|
274 |
<p>
|
|
|
275 |
Currently, all images are decompressed by the interpreter before being
|
|
|
276 |
passed to the graphics library; the PDF writer may then compress them again.
|
|
|
277 |
Ordinarily, this only slows things down a little, but in the case of
|
|
|
278 |
DCT-encoded images that are being DCT-encoded in the output, image
|
|
|
279 |
degradation may occur. Ideally, the implementation should be smart enough
|
|
|
280 |
to not decode and re-encode the image. However, making this work properly
|
|
|
281 |
is difficult. <I>This would probably involve extending the library APIs for
|
|
|
282 |
images so that they could pass a stream, possibly including filters, instead
|
|
|
283 |
of the (fully decoded) data rows.</I>
|
|
|
284 |
|
|
|
285 |
<h3>Emit warnings when producing PDF output.</h3>
|
|
|
286 |
|
|
|
287 |
<p>
|
|
|
288 |
Currently, the PDF writer has no way to emit warnings. Users would like to
|
|
|
289 |
see warnings when fonts cannot be embedded (this is actually required when
|
|
|
290 |
the value of CannotEmbedFontPolicy is set to /Warning), and for some other
|
|
|
291 |
questionable situations like non-existent Dests (Feature request
|
|
|
292 |
<a href="http://bugs.ghostscript.com/show_bug.cgi?id=480853"
|
|
|
293 |
class="offsite">#480853</a>).
|
|
|
294 |
Probably the right way to handle this is with a pseudo device parameter
|
|
|
295 |
called "Warnings" that is a list of strings: the pdfwrite driver would add
|
|
|
296 |
strings to this list, and the ps2pdf script (lib/gs_pdfwr.ps) would read
|
|
|
297 |
them out, print them, and reset them at the end of each page.
|
|
|
298 |
|
|
|
299 |
<hr>
|
|
|
300 |
|
|
|
301 |
<h2><a name="Graphics_functionality"></a>Graphics functionality</h2>
|
|
|
302 |
|
|
|
303 |
<h3>Support for 64-bit colors on 64-bit platforms.</h3>
|
|
|
304 |
|
|
|
305 |
<p>
|
|
|
306 |
Currently, the library supports a maximum of 32 bits of data per pixel; we
|
|
|
307 |
would like to raise this limit to 64 bits on systems where the 'long' data
|
|
|
308 |
type is 64 bits wide. <I>The <b><tt>gx_color_index</tt></b>
|
|
|
309 |
type is already defined as 'long', but there are many places where the type
|
|
|
310 |
<b><tt>bits32</tt></b> is used for pixel values; there is a 32-bit
|
|
|
311 |
stored-image "device", but there is no 64-bit device; a few algorithms and
|
|
|
312 |
tables have knowledge of the 32-bit width built into them, only because the
|
|
|
313 |
C preprocessor doesn't have any kind of loop or repetition
|
|
|
314 |
capability.</I>
|
|
|
315 |
|
|
|
316 |
<h3>In-RIP trapping.</h3>
|
|
|
317 |
|
|
|
318 |
<p>
|
|
|
319 |
The PostScript specification includes an option for the interpreter to
|
|
|
320 |
implement trapping (adjustments of object boundaries to prevent visual
|
|
|
321 |
anomalies caused by slight misregistration of different ink layers): we
|
|
|
322 |
would like to implement this. <I>This is a complex and
|
|
|
323 |
difficult area; even many Adobe RIPs don't do it.</I>
|
|
|
324 |
|
|
|
325 |
<h3>Improve the font grid fitting and antialiasing.</h3>
|
|
|
326 |
|
|
|
327 |
<p>
|
|
|
328 |
Ghostscript includes a reduced True Type bytecode interpreter branched from FreeType 1.
|
|
|
329 |
It performs a grid fitting for True Type glyphs except ones involving
|
|
|
330 |
instructions patented by Apple. A wanted improvement is to implement
|
|
|
331 |
a stem recognition algorithm similar to Free Type autohinting.
|
|
|
332 |
It also would help to poorly designed Type 1 fonts, which have misplaced or missed hints.
|
|
|
333 |
|
|
|
334 |
<p>
|
|
|
335 |
Another useful improvement is to implement a font antialiasing with
|
|
|
336 |
<b><tt>TextAlphaBits</tt></b> other than 1,2,4.
|
|
|
337 |
|
|
|
338 |
<h3>ICC profile support for output.</h3>
|
|
|
339 |
|
|
|
340 |
<p>
|
|
|
341 |
Ghostscript 7.00 and later supports ICCBased color spaces of PDF
|
|
|
342 |
using the icclib package from
|
|
|
343 |
<a href="http://web.access.net.au/argyll/color.html ">
|
|
|
344 |
http://web.access.net.au/argyll/color.html</a>
|
|
|
345 |
but there is no facility to use ICC output (printer) profiles that
|
|
|
346 |
may be embedded in the PDF. Also it would be useful for PostScript
|
|
|
347 |
to be able to directly use a specific Intent from ICC profile to
|
|
|
348 |
convert output colors (as CRD's are now used).
|
|
|
349 |
<I>The primary difficulty is that the graphics library and PostScript
|
|
|
350 |
always use CIE XYZ as the connection space, but ICC profiles may
|
|
|
351 |
use CIELAB as the connection space, requiring conversion for use
|
|
|
352 |
with the graphics library. </I>
|
|
|
353 |
|
|
|
354 |
<h3>Making halftones into "objects" and adding new types.</h3>
|
|
|
355 |
|
|
|
356 |
<p>
|
|
|
357 |
Currently, knowledge of the specific data formats and algorithms for
|
|
|
358 |
halftoning permeates too many places in the library. We would like
|
|
|
359 |
halftoning to be more "object oriented" (using virtual procedures) so that
|
|
|
360 |
we could support other halftoning methods such as direct use of threshold
|
|
|
361 |
arrays, or the double-rectangle approach added in newer PostScript versions.
|
|
|
362 |
<I>Threshold arrays take much less space than the current
|
|
|
363 |
representation, generally at the expense of longer rendering time for
|
|
|
364 |
black-and-white images; double-rectangle representation would give us a
|
|
|
365 |
better implementation of AccurateScreens. We might want store both
|
|
|
366 |
threshold arrays and the current representation.</I>
|
|
|
367 |
|
|
|
368 |
<h3>Factor out error diffusion routines, integrate ETS.</h3>
|
|
|
369 |
|
|
|
370 |
<p>
|
|
|
371 |
Currently, several different inkjet drivers implement their own, very
|
|
|
372 |
similar but slightly differing error diffusion methods. This has caused
|
|
|
373 |
severe code bloat as well as tempting future driver writers to contribute to
|
|
|
374 |
it further. We want to factor out error diffusion into a common set of
|
|
|
375 |
facilities that drivers can use. <I>We would like to design
|
|
|
376 |
these facilities so that they can easily interface to the Even-Toned
|
|
|
377 |
Screening algorithms from artofcode (Raph Levien), to the extent that these
|
|
|
378 |
will be Open Source.</I>
|
|
|
379 |
|
|
|
380 |
<h3>Improve, or generalize, linearization for stochastic threshold
|
|
|
381 |
data.</h3>
|
|
|
382 |
|
|
|
383 |
<p>
|
|
|
384 |
The Ghostscript distribution includes a stochastic threshold array. This
|
|
|
385 |
array has some gamma correction built into it, which works well for some
|
|
|
386 |
output devices and not for others. We would like to provide a version of
|
|
|
387 |
this array without (or with less) gamma correction. <I>We have
|
|
|
388 |
original data available from which this could be done fairly easily.</I>
|
|
|
389 |
|
|
|
390 |
<h3>Change sampled functions to use new interpreted functions.</h3>
|
|
|
391 |
|
|
|
392 |
<p>
|
|
|
393 |
The PostScript language defines many functions relevant to graphics
|
|
|
394 |
rendering as being implemented by arbitrary PostScript procedures: transfer
|
|
|
395 |
(gamma correction), black generation, undercolor removal, several stages of
|
|
|
396 |
CIE color space and rendering, and color mapping for Separation and DeviceN
|
|
|
397 |
spaces. Since the graphics library can't call PostScript procedures,
|
|
|
398 |
Ghostscript currently samples these procedures at a fixed number of points
|
|
|
399 |
and interpolates linearly between the samples. As of Ghostscript 6.20, the
|
|
|
400 |
library can interpret a restricted subset of PostScript procedures directly
|
|
|
401 |
(basically those that only use arithmetic and comparisons: no loops,
|
|
|
402 |
sub-procedures, or data structures). Changing the rendering functions to
|
|
|
403 |
use this approach when possible would greatly improve output quality when
|
|
|
404 |
the functions are very non-linear (which we have actually seen in practice).
|
|
|
405 |
<I>This should only be done if the function is, in fact,
|
|
|
406 |
severely non-linear, since interpreting the function definition will almost
|
|
|
407 |
always be much slower than interpolating in the table.</I>
|
|
|
408 |
|
|
|
409 |
<h3>Replace PostScript procedures with Function objects.</h3>
|
|
|
410 |
|
|
|
411 |
<p>
|
|
|
412 |
Currently, there is a lot of tiresome code for doing callbacks with
|
|
|
413 |
continuations for loading the caches that hold sampled values for the
|
|
|
414 |
procedures listed under "Change sampled functions ..." above. For the
|
|
|
415 |
Separation and DeviceN tint transform functions, and only for these,
|
|
|
416 |
PostScript code associated with the setcolorspace operator actually converts
|
|
|
417 |
the PostScript procedure to a Function object -- to a FunctionType 4
|
|
|
418 |
(PostScript subset) Function if possible, or to a FunctionType 0 (sampled)
|
|
|
419 |
Function if not. This approach should be used for all the other sampled
|
|
|
420 |
functions. Doing this would reduce the amount of C code significantly,
|
|
|
421 |
while only increasing PostScript code slightly.
|
|
|
422 |
|
|
|
423 |
<p>
|
|
|
424 |
This change would require touching (and slightly changing) all PostScript
|
|
|
425 |
operators that currently do such callbacks: for example, rather than a
|
|
|
426 |
setblackgeneration operator that takes a PostScript procedure as its
|
|
|
427 |
operand, we would have a .setblackgeneration operator that takes as operands
|
|
|
428 |
both the PostScript procedure (so that currentblackgeneration can return it)
|
|
|
429 |
*and* a Function derived from it (which will actually be used when loading
|
|
|
430 |
the cache, or for sampling directly if desired).
|
|
|
431 |
|
|
|
432 |
<p>
|
|
|
433 |
In some cases, this approach has a non-negligible space cost. If the
|
|
|
434 |
PostScript procedure cannot be represented as a FunctionType 4 Function, it
|
|
|
435 |
must be sampled and represented as a FunctionType 0 Function. Then the BG /
|
|
|
436 |
UCR / transfer / ... cache will essentially just hold a copy of the Function
|
|
|
437 |
data. While it is likely that this situation will be rare in practice, it
|
|
|
438 |
might be worth looking into changing the internal representation of these
|
|
|
439 |
caches so that they were the same as the representation of a FunctionType 0
|
|
|
440 |
Function with a particular choice of parameters. Then the PostScript code
|
|
|
441 |
that called .buildsampledfunction when necessary could arrange the
|
|
|
442 |
parameters to have the same values as the internal representation of the
|
|
|
443 |
cache, and the cache could use the Function data directly. This is probably
|
|
|
444 |
not worth the trouble.
|
|
|
445 |
|
|
|
446 |
<h3>Add optional cubic interpolation to RenderTable and other table
|
|
|
447 |
lookup.</h3>
|
|
|
448 |
|
|
|
449 |
<p>
|
|
|
450 |
Currently, if a CIE rendering dictionary uses a lookup table for the final
|
|
|
451 |
step, Ghostscript always interpolates linearly between the entries. Cubic
|
|
|
452 |
interpolation should be supported as an option. A cubic interpolation
|
|
|
453 |
option is also needed for general table-lookup Functions.
|
|
|
454 |
|
|
|
455 |
<h3>Add better (SVG-like) alpha channel and compositing to library.</h3>
|
|
|
456 |
|
|
|
457 |
<p>
|
|
|
458 |
Ghostscript has partial support for alpha channel and for alpha and RasterOp
|
|
|
459 |
compositing. There is some architectural support for general compositing,
|
|
|
460 |
but it postdates the RasterOp implementation, and most of the RasterOp code
|
|
|
461 |
doesn't use it. We expect that the more extensive compositing and alpha
|
|
|
462 |
capabilities of SVG will find their way into PDF (and probably PostScript as
|
|
|
463 |
well) in the course of 2000 and 2001, and we will need to implement them.
|
|
|
464 |
|
|
|
465 |
<hr>
|
|
|
466 |
|
|
|
467 |
<h2><a name="Performance"></a>Performance</h2>
|
|
|
468 |
|
|
|
469 |
<h3>Change band list logic to defer halftoning until rendering.</h3>
|
|
|
470 |
|
|
|
471 |
<p>
|
|
|
472 |
Currently, when Ghostscript uses a band list, it does halftoning before
|
|
|
473 |
banding. It should do halftoning after banding: this produces smaller band
|
|
|
474 |
lists and shifts more work to the rasterizer (which is good because the
|
|
|
475 |
rasterizer can be multi-threaded internally for higher performance on
|
|
|
476 |
multiprocessors: see the next topic.)
|
|
|
477 |
|
|
|
478 |
<h3>Reduce redundant data for smoothed banded images.</h3>
|
|
|
479 |
|
|
|
480 |
<p>
|
|
|
481 |
When smoothed ("interpolated") images are written in the band list, extra
|
|
|
482 |
rows must be written above and below each band in order to provide the data
|
|
|
483 |
for interpolation. Currently, the number of such rows is computed very
|
|
|
484 |
conservatively; instead, the final interpolation algorithm should be
|
|
|
485 |
consulted to provide the correct value. <i>This is a small task.</i>
|
|
|
486 |
|
|
|
487 |
<h3>Multi-threaded rasterizing</h3>
|
|
|
488 |
|
|
|
489 |
<p>
|
|
|
490 |
For high-resolution devices, rasterization dominates execution time. On
|
|
|
491 |
multiprocessor systems, Ghostscript can do tasks in parallel:
|
|
|
492 |
|
|
|
493 |
<ul>
|
|
|
494 |
|
|
|
495 |
<li>Rasterize multiple bands simultaneously;
|
|
|
496 |
|
|
|
497 |
<li>Rasterize multiple color planes of a single band simultaneously (if a
|
|
|
498 |
planar representation is being used);
|
|
|
499 |
|
|
|
500 |
<li>For some computation-intensive tasks like smoothing images or filling
|
|
|
501 |
large regions, partition the task (possibly buffering more data to allow
|
|
|
502 |
larger-grain partitioning) and execute several partitions simultaneously.
|
|
|
503 |
|
|
|
504 |
</ul>
|
|
|
505 |
|
|
|
506 |
<p>
|
|
|
507 |
We would want these facilities implemented so that no conditional
|
|
|
508 |
compilation was involved: on uniprocessor systems, the locking API would
|
|
|
509 |
simply have a vacuous implementation.
|
|
|
510 |
|
|
|
511 |
<h3>Notification for glyph decaching.</h3>
|
|
|
512 |
|
|
|
513 |
<p>
|
|
|
514 |
Currently, drivers can't do a very good job of downloading rendered
|
|
|
515 |
character bitmaps to the device they manage, because they can't find out
|
|
|
516 |
when a bitmap is being deleted from Ghostscript's cache and therefore will
|
|
|
517 |
never be referenced again. Here is a sketch of how we would add this
|
|
|
518 |
capability to the graphics library:
|
|
|
519 |
|
|
|
520 |
<ul>
|
|
|
521 |
|
|
|
522 |
<li>The driver would implement the <b><tt>text_begin</tt></b> call, simply
|
|
|
523 |
to get access to a <b><tt>gs_imager_state</tt></b> that references the
|
|
|
524 |
rendered character cache. (The driver could always simply call the default
|
|
|
525 |
implementation of <b><tt>text_begin</tt></b>.)
|
|
|
526 |
|
|
|
527 |
<li>In the <b><tt>text_begin</tt></b> procedure, the driver would call
|
|
|
528 |
|
|
|
529 |
<blockquote><pre>
|
|
|
530 |
gs_glyph_decache_register(imager_state, notify_proc, proc_data)
|
|
|
531 |
</pre></blockquote>
|
|
|
532 |
|
|
|
533 |
<p>
|
|
|
534 |
where <b><tt>proc_data</tt></b> was, or pointed to a structure that
|
|
|
535 |
included, a pointer to the driver.
|
|
|
536 |
|
|
|
537 |
<li><b><tt>gs_glyph_decache_register</tt></b> would use the general
|
|
|
538 |
notification mechanism defined in <b><tt>gsnotify.h</tt></b> to call
|
|
|
539 |
|
|
|
540 |
<blockquote><pre>
|
|
|
541 |
notify_proc(proc_data, pchar_data)
|
|
|
542 |
</pre></blockquote>
|
|
|
543 |
|
|
|
544 |
<p>
|
|
|
545 |
whenever a bitmap was removed from the character cache.
|
|
|
546 |
<b><tt>pchar_data</tt></b> would point to some identification of the
|
|
|
547 |
character; perhaps just the bitmap ID, but possibly a
|
|
|
548 |
<b><tt>gx_cached_bits_common</tt></b> or even a <b><tt>cached_char</tt></b>.
|
|
|
549 |
|
|
|
550 |
<li>The <b><tt>char_cache</tt></b> structure would be need an additional
|
|
|
551 |
member, a <b><tt>gs_notify_list_t</tt></b>. It would also need to add
|
|
|
552 |
finalization so that when it was freed, it would notify and unregister all
|
|
|
553 |
clients, using <b><tt>gs_notify_all(list, NULL)</tt></b> and then
|
|
|
554 |
<b><tt>gs_notify_release</tt></b>.
|
|
|
555 |
|
|
|
556 |
</ul>
|
|
|
557 |
|
|
|
558 |
<p>
|
|
|
559 |
<I>This facility was requested by the Display Ghostscript project, but it
|
|
|
560 |
could also be used to improve the output of the PCL XL driver and possibly
|
|
|
561 |
the X and PCL5 drivers.</I>
|
|
|
562 |
|
|
|
563 |
<hr>
|
|
|
564 |
|
|
|
565 |
<h2><a name="Other_functionality"></a>Other functionality</h2>
|
|
|
566 |
|
|
|
567 |
<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3>
|
|
|
568 |
|
|
|
569 |
<p>
|
|
|
570 |
There is a project to create a GNU implementation of the OPENStep API, which
|
|
|
571 |
involves extending Ghostscript to provide the full functionality of Adobe's
|
|
|
572 |
Display PostScript system with some of the NeXT extensions. For more
|
|
|
573 |
information, please contact Net-Community <<a
|
|
|
574 |
href="mailto:scottc@net-community.com">scottc@net-community.com</a>>.
|
|
|
575 |
|
|
|
576 |
<h3>Job Server implementation.</h3>
|
|
|
577 |
|
|
|
578 |
<p>
|
|
|
579 |
For full Adobe PostScript compatibility, Ghostscript needs a real "job
|
|
|
580 |
server" to encapsulate the execution of PostScript files.
|
|
|
581 |
<I>See the section on "Job Execution Environment" in the PostScript
|
|
|
582 |
Language Reference Manual for details.</I>
|
|
|
583 |
|
|
|
584 |
<h3>SVG (XML Structured Vector Graphics) interpreter.</h3>
|
|
|
585 |
|
|
|
586 |
<p>
|
|
|
587 |
Ghostscript could be adapted with some work to read SVG. This would be an
|
|
|
588 |
interesting and challenging project because SVG's graphics model would
|
|
|
589 |
require extending the library (see above). <I>If SVG turns out to be an
|
|
|
590 |
important standard, it is important that there be a good free implementation
|
|
|
591 |
of it.</I>
|
|
|
592 |
|
|
|
593 |
<h3><b><tt>%font%</tt></b> and other IODevices.</h3>
|
|
|
594 |
|
|
|
595 |
<p>
|
|
|
596 |
Currently, the <b><tt>%font%</tt></b> IODevice is not implemented. We would
|
|
|
597 |
like to see this implemented using a general framework for implementing
|
|
|
598 |
IODevices (%xxxx%) entirely in PostScript, in an "object oriented" manner
|
|
|
599 |
very similiar to the way Resource categories are implemented. An IODevice
|
|
|
600 |
would be implemented as a dictionary with the following keys, whose values
|
|
|
601 |
would be procedures that implemented the corresponding operation:
|
|
|
602 |
|
|
|
603 |
<blockquote><pre>
|
|
|
604 |
/File
|
|
|
605 |
/DeleteFile
|
|
|
606 |
/RenameFile
|
|
|
607 |
/Status
|
|
|
608 |
/FileNameForAll
|
|
|
609 |
/GetDevParams
|
|
|
610 |
/PutDevParams
|
|
|
611 |
</pre></blockquote>
|
|
|
612 |
|
|
|
613 |
<p>
|
|
|
614 |
There would only be global IODevices, no local ones; the dictionary keeping
|
|
|
615 |
track of them would be stored in global VM.
|
|
|
616 |
|
|
|
617 |
<p>
|
|
|
618 |
<I>This is an obscure feature that matters only because some PostScript code
|
|
|
619 |
uses <b><tt>filenameforall</tt></b> with this IODevice, rather than
|
|
|
620 |
<b><tt>filenameforall</tt></b> with the <b><tt>/Font</tt></b> Resource
|
|
|
621 |
category, to enumerate available fonts.</I>
|
|
|
622 |
|
|
|
623 |
<h3>Repairing damaged or EOL-converted PDF files.</h3>
|
|
|
624 |
|
|
|
625 |
<p>
|
|
|
626 |
Adobe Acrobat Reader can scan a PDF file that has had its end-of-lines
|
|
|
627 |
converted by careless users transferring the file across operating systems
|
|
|
628 |
as text rather than binary across, and reconstruct the cross-reference table
|
|
|
629 |
which the PDF interpreter requires. This only works if the file has no
|
|
|
630 |
binary data in it, which with PDF 1.3 is rarely the case. However, users
|
|
|
631 |
occasionally receive PDF files that have been damaged in this way, and it
|
|
|
632 |
might be useful to have a program that can repair them. <I>We think this
|
|
|
633 |
should probably be done as a separate program, possibly in PostScript,
|
|
|
634 |
similar to Ghostscript's PDF linearizer.</I>
|
|
|
635 |
|
|
|
636 |
<h2><a name="Other_implementation"></a>Implementation improvements</h2>
|
|
|
637 |
|
|
|
638 |
<h3>Fully re-entrant code.</h3>
|
|
|
639 |
|
|
|
640 |
<p>
|
|
|
641 |
Currently, neither the PostScript interpreter nor the graphics library is
|
|
|
642 |
fully re-entrant (no writable globals). Making them fully re-entrant would
|
|
|
643 |
make Ghostscript usable in multi-threaded environments, and more easily
|
|
|
644 |
usable in embedded environments. Note that this is necessary, but far from
|
|
|
645 |
sufficient, for Ghostscript to allow simultaneous execution of a single
|
|
|
646 |
Ghostscript interpreter instance by multiple threads: that is probably
|
|
|
647 |
permanently out of the question. <I>Almost all drivers, including all of
|
|
|
648 |
the drivers in devs.mak which are maintained as part of the main Ghostscript
|
|
|
649 |
code, are already fully re-entrant; making the remaining ones re-entrant
|
|
|
650 |
should really be up to the driver author.</I>
|
|
|
651 |
|
|
|
652 |
<h3>Ghostscript has no %ram% device.</h3>
|
|
|
653 |
|
|
|
654 |
<p>
|
|
|
655 |
The %ram% device is documented in PS Supplement 3010 and 3011 dated August 30, 1999.
|
|
|
656 |
This is probably not a major impediment to portability, but it would be handy.
|
|
|
657 |
<p><I>
|
|
|
658 |
On Unix, the suggested implementation would be to create a subdirectory
|
|
|
659 |
of the temporary directory (usually /tmp), with the name chosen and the
|
|
|
660 |
directory created in such a way as to avoid /tmp races and similar
|
|
|
661 |
problems. Ghostscript should delete the subdirectory when it exits.
|
|
|
662 |
</I>
|
|
|
663 |
|
|
|
664 |
<!-- [2.0 end contents] ==================================================== -->
|
|
|
665 |
|
|
|
666 |
<!-- [3.0 begin visible trailer] =========================================== -->
|
|
|
667 |
<hr>
|
|
|
668 |
|
|
|
669 |
<p>
|
|
|
670 |
<small>Copyright © 2000 Aladdin Enterprises. All rights
|
|
|
671 |
reserved.</small>
|
|
|
672 |
|
|
|
673 |
<p>
|
|
|
674 |
This software is provided AS-IS with no warranty, either express or
|
|
|
675 |
implied.
|
|
|
676 |
|
|
|
677 |
This software is distributed under license and may not be copied,
|
|
|
678 |
modified or distributed except as expressly authorized under the terms
|
|
|
679 |
of the license contained in the file LICENSE in this distribution.
|
|
|
680 |
|
|
|
681 |
For more information about licensing, please refer to
|
|
|
682 |
http://www.ghostscript.com/licensing/. For information on
|
|
|
683 |
commercial licensing, go to http://www.artifex.com/licensing/ or
|
|
|
684 |
contact Artifex Software, Inc., 101 Lucas Valley Road #110,
|
|
|
685 |
San Rafael, CA 94903, U.S.A., +1(415)492-9861.
|
|
|
686 |
|
|
|
687 |
<p>
|
|
|
688 |
<small>Ghostscript version 8.53, 20 October 2005
|
|
|
689 |
|
|
|
690 |
<!-- [3.0 end visible trailer] ============================================= -->
|
|
|
691 |
|
|
|
692 |
</body>
|
|
|
693 |
</html>
|