| 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 Open Issues.</title>
|
|
|
5 |
<!-- $Id: Issues.htm,v 1.52 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>Known limitations and minor bugs.</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="#Known_Limitations">Known Limitations</a>
|
|
|
24 |
<li><a href="#Minor_bugs">Minor bugs</a>
|
|
|
25 |
<li><a href="#Driver_Issues">Specific Driver Issues</a>
|
|
|
26 |
<li><a href="#Performance">Performance</a>
|
|
|
27 |
<li><a href="#Differences_from_Adobe">Differences from Adobe Implementation</a>
|
|
|
28 |
</ul>
|
|
|
29 |
|
|
|
30 |
<!-- [1.2 end table of contents] =========================================== -->
|
|
|
31 |
|
|
|
32 |
<!-- [1.3 begin hint] ====================================================== -->
|
|
|
33 |
|
|
|
34 |
<p>For other information, see the <a href="Projects.htm">Development Projects list
|
|
|
35 |
</a>.
|
|
|
36 |
|
|
|
37 |
<!-- [1.3 end hint] ======================================================== -->
|
|
|
38 |
|
|
|
39 |
<hr>
|
|
|
40 |
|
|
|
41 |
<!-- [1.0 end visible header] ============================================== -->
|
|
|
42 |
|
|
|
43 |
<!-- [2.0 begin contents] ================================================== -->
|
|
|
44 |
|
|
|
45 |
<p>
|
|
|
46 |
There are many areas that might make Ghostscript more useful or minor bugs
|
|
|
47 |
that we would like to investigate and possibly fix, but for which we don't
|
|
|
48 |
have enough resources. These may or may not be addressed in future releases.
|
|
|
49 |
<p>
|
|
|
50 |
If you would like to take responsibility for any of these issues, please
|
|
|
51 |
<a href="mailto:raph@artofcode.com">contact us</a>.
|
|
|
52 |
<p>
|
|
|
53 |
Additional comments on implementation approaches or project goals are in
|
|
|
54 |
<I>italic type like this</I>.
|
|
|
55 |
<hr>
|
|
|
56 |
|
|
|
57 |
<h2><a name="Known_Limitations"></a>Known Limitations.</h2>
|
|
|
58 |
|
|
|
59 |
<h3>bbox device doesn't allow min coords < 0.</h3>
|
|
|
60 |
Adobe eps specification doesn't say that bbox values must be positive,
|
|
|
61 |
and, for example Adobe Illustrator, can create EPS files with negative bboxes.
|
|
|
62 |
In such case, Ghostscipt returns zero instead of proper negative number.
|
|
|
63 |
<p>
|
|
|
64 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=202735"
|
|
|
65 |
class="offsite">#202735</a>, March 09, 2000.
|
|
|
66 |
<p>
|
|
|
67 |
<I>
|
|
|
68 |
This might be able to be fixed by applying a large positive translation to
|
|
|
69 |
the bbox CTM which would be subtracted from coordinates passed to the target
|
|
|
70 |
device as well as from the results the bbox device reports.
|
|
|
71 |
<p>
|
|
|
72 |
If coordinates for the ImagingBBox[0] and [1] values, then negative
|
|
|
73 |
values are handled, but this is not reliable since there are places in
|
|
|
74 |
the graphics library that depend on first quadrant coordinates.
|
|
|
75 |
</I>
|
|
|
76 |
|
|
|
77 |
<h3>Error messages are too low level and confusing.</h3>
|
|
|
78 |
|
|
|
79 |
<p>
|
|
|
80 |
Although technically correct many error messages are confusing for
|
|
|
81 |
end users. Some commonly reported examples are listed below.
|
|
|
82 |
|
|
|
83 |
<p>
|
|
|
84 |
When pdfwrite device cannot open the output file it fails with:
|
|
|
85 |
<pre>**** Unable to open the initial device, quitting.</pre>
|
|
|
86 |
|
|
|
87 |
When CIDFont-CMap pair required by PDF file is not available GS
|
|
|
88 |
fails with:
|
|
|
89 |
<blockquote><pre>/undefinedresource in --findresource--</pre></blockquote>
|
|
|
90 |
|
|
|
91 |
|
|
|
92 |
<h3>pswrite device generates low level PostScript.</h3>
|
|
|
93 |
|
|
|
94 |
<p>
|
|
|
95 |
pswrite and epswrite devices reduce everything to path, fill, stroke, clip
|
|
|
96 |
image, and imagemask operations. Although the resulting file
|
|
|
97 |
prints OK it produces unsatisfactory results when scaled,
|
|
|
98 |
distilled or imported into graphic editors.
|
|
|
99 |
The file can easily exceed 4GB and hit file size limits
|
|
|
100 |
in some applications or operation systems. Handling of big files is
|
|
|
101 |
slow.
|
|
|
102 |
<p>
|
|
|
103 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615165"
|
|
|
104 |
class="offsite">#615165</a>, September 26, 2002.
|
|
|
105 |
<hr>
|
|
|
106 |
<h2><a name="Minor_bugs"></a>Minor Bugs.</h2>
|
|
|
107 |
|
|
|
108 |
<h3> Bad JPEG stream in PDF generated when source ends prematurely</h3>
|
|
|
109 |
When GS converts the source image to JPEG stream in PDF file and the
|
|
|
110 |
source data end prematurely, it generates bad JPEG stream.
|
|
|
111 |
tiff2ps from libtiff distribution often generates such files.
|
|
|
112 |
<p>
|
|
|
113 |
One potential workaround is to use -dAutoFilterColorImages=false and
|
|
|
114 |
-dColorImageFilter=/FlateEncode.
|
|
|
115 |
<p>
|
|
|
116 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=228808"
|
|
|
117 |
class="offsite">#228808</a>, Jan 15, 2000.
|
|
|
118 |
<p>
|
|
|
119 |
<I>
|
|
|
120 |
JPEG stream writes image dimensions in JPEG header when the stream is created.
|
|
|
121 |
When the source data end the dimensions are not updated. There may be other
|
|
|
122 |
problems too.
|
|
|
123 |
</I>
|
|
|
124 |
|
|
|
125 |
<h3> Some attributes of Catalog object are lost during PDF to PDF conversion</h3>
|
|
|
126 |
Dests, OpenAction, URI, PageMode, ViewerPreferences are lost during PDF to PDF
|
|
|
127 |
conversion. Other attributes have not been checked.
|
|
|
128 |
<p>
|
|
|
129 |
<I>
|
|
|
130 |
The loss happens diring PDF interpretation. GS can generate these attributes
|
|
|
131 |
from pdfmark's.
|
|
|
132 |
</I>
|
|
|
133 |
<p>
|
|
|
134 |
March 25, 2001.
|
|
|
135 |
<h3>ps2pdf ignores transfer functions in shaded fill</h3>
|
|
|
136 |
ps2pdf ignores transfer functions in the shaded fill but
|
|
|
137 |
uses them for vector objects. The following sample program
|
|
|
138 |
has 2 shaded fills and 2 rectangles that should have the
|
|
|
139 |
same color as the left end of the shaded fill.
|
|
|
140 |
<blockquote><pre>
|
|
|
141 |
|
|
|
142 |
%!
|
|
|
143 |
<</PageSize [612 200] /Policies<</PageSize 1>> >>setpagedevice
|
|
|
144 |
612 1 scale
|
|
|
145 |
/grad
|
|
|
146 |
{ gsave
|
|
|
147 |
|
|
|
148 |
<<
|
|
|
149 |
/ColorSpace [/DeviceCMYK]
|
|
|
150 |
/Domain [0 1]
|
|
|
151 |
/Coords [0 0 1 0]
|
|
|
152 |
/Extend [false false]
|
|
|
153 |
/Function
|
|
|
154 |
<< /FunctionType 3
|
|
|
155 |
/Domain [ 0 1]
|
|
|
156 |
/Functions
|
|
|
157 |
[ <<
|
|
|
158 |
/FunctionType 2
|
|
|
159 |
/N 1
|
|
|
160 |
/C0 [ 0 0.5 0 0 ]
|
|
|
161 |
/Domain [ 0 1]
|
|
|
162 |
/C1 [0.5 0 0 0]
|
|
|
163 |
>> ]
|
|
|
164 |
/Bounds []
|
|
|
165 |
/Encode [0 1]
|
|
|
166 |
>>
|
|
|
167 |
/ShadingType 2
|
|
|
168 |
>> shfill
|
|
|
169 |
|
|
|
170 |
|
|
|
171 |
|
|
|
172 |
grestore
|
|
|
173 |
} def
|
|
|
174 |
|
|
|
175 |
grad
|
|
|
176 |
{1 exch 2 div sub} settransfer
|
|
|
177 |
|
|
|
178 |
grad
|
|
|
179 |
showpage
|
|
|
180 |
|
|
|
181 |
</pre></blockquote>
|
|
|
182 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=232334"
|
|
|
183 |
class="offsite">#232334</a>, February 14, 2001.
|
|
|
184 |
|
|
|
185 |
<h3>ResourceFileName gives wrong result with Font category.</h3>
|
|
|
186 |
The following sequence:
|
|
|
187 |
|
|
|
188 |
<blockquote><pre>
|
|
|
189 |
/Font /Category findresource begin
|
|
|
190 |
/CharterBT-Roman 255 string ResourceFileName =
|
|
|
191 |
end
|
|
|
192 |
</pre></blockquote>
|
|
|
193 |
|
|
|
194 |
Gives the results:
|
|
|
195 |
<pre>
|
|
|
196 |
/Resource/Font/CharterBT-Roman
|
|
|
197 |
</pre>
|
|
|
198 |
|
|
|
199 |
This should be a valid platform specific file name and path such as:
|
|
|
200 |
<pre>
|
|
|
201 |
f:/afpl/fonts/bchr.pfa
|
|
|
202 |
</pre>
|
|
|
203 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=233403"
|
|
|
204 |
class="offsite">#233403</a>, February 21, 2001.
|
|
|
205 |
<h3>GS doesn't handle names of separations with HalftoneType 5.</h3>
|
|
|
206 |
PLRM3 says, that HalftoneType 5 may use user defined
|
|
|
207 |
names of separations. Neither zht2.c nor cmd_put_drawing_color in
|
|
|
208 |
gxclpath.c can handle this. GS chooses default halftone component
|
|
|
209 |
for any non-standard separation name.
|
|
|
210 |
<p>
|
|
|
211 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643"
|
|
|
212 |
class="offsite">#406643</a>, March 7, 2001.
|
|
|
213 |
|
|
|
214 |
<h3> PDF 1.4 images don't deallocate all memory </h3>
|
|
|
215 |
|
|
|
216 |
<p>
|
|
|
217 |
The pdf14_begin_typed_image() function in the PDF 1.4 device creates
|
|
|
218 |
a marking device, but this is not freed on end_image. The garbage
|
|
|
219 |
collector will free it, so it's not a real memory leak, but it would
|
|
|
220 |
still be nicer to free it explicitly.
|
|
|
221 |
|
|
|
222 |
<h3> Truetype fonts are written with incorrect table checksums </h3>
|
|
|
223 |
|
|
|
224 |
<p>
|
|
|
225 |
psf_write_truetype_data() writes truetype fonts with incorrect
|
|
|
226 |
checksums on most tables. Most truetype interpreters ignore these
|
|
|
227 |
so in practice the issue hasn't been a problem. Nevertheless,
|
|
|
228 |
Ghostscript is embedding off-spec fonts in pdf documents.
|
|
|
229 |
|
|
|
230 |
<p>
|
|
|
231 |
A complete fix should generate font data in 2 passes: the
|
|
|
232 |
first pass computes the checksums, the second one
|
|
|
233 |
really writes data. Fonts can be very large, so
|
|
|
234 |
buffering the entire font is not a good solution. The
|
|
|
235 |
checksums can't be modified after the data is written
|
|
|
236 |
because the output stream may not be positionable
|
|
|
237 |
(likely it's a FlateEncode filter).
|
|
|
238 |
|
|
|
239 |
<p>
|
|
|
240 |
<i>Igor suggests implementing a special encoding filter for
|
|
|
241 |
checksums, and executing the body of
|
|
|
242 |
psf_write_truetype_data twice: first with the checksum
|
|
|
243 |
filter, second with the real output stream. After a TT
|
|
|
244 |
table is completed, its checksum to be taken from the
|
|
|
245 |
filter and to be put into the 'tables' array.</i>
|
|
|
246 |
|
|
|
247 |
<p>
|
|
|
248 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615620"
|
|
|
249 |
class="offsite">#615620</a>, September 27, 2002.
|
|
|
250 |
|
|
|
251 |
<h3> save restore fails from the command line </h3>
|
|
|
252 |
|
|
|
253 |
<p>
|
|
|
254 |
Entering 'save' followed by 'restore' from the interactive
|
|
|
255 |
Ghostscript prompt (on separate lines) generates an /invalidrestore
|
|
|
256 |
exception. It shouldn't. This is a long standing issue.
|
|
|
257 |
|
|
|
258 |
<p>
|
|
|
259 |
The problem is that the string that is used
|
|
|
260 |
for command line input by the 'executive'
|
|
|
261 |
processing still exists when the 'restore'
|
|
|
262 |
happens, but this string is brought into
|
|
|
263 |
existence after the 'save' operation, thus
|
|
|
264 |
an causing an invalidrestore.
|
|
|
265 |
|
|
|
266 |
<p>
|
|
|
267 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=603689"
|
|
|
268 |
class="offsite">#603689</a>, September 2, 2002.
|
|
|
269 |
|
|
|
270 |
<h3> Failure to repair incorrect component ids in JPEG images </h3>
|
|
|
271 |
|
|
|
272 |
<p>There are PDF files in the wild containing JPEG images with
|
|
|
273 |
incorrect component id tags. Ghostscript currently displays these
|
|
|
274 |
files incorrectly, but in the past the files displayed fine. The
|
|
|
275 |
problem is not in Ghostscript itself, though, but in the libjpeg
|
|
|
276 |
library.
|
|
|
277 |
|
|
|
278 |
<p>Behavior changed in recent libjpeg versions; libjpeg version 6a
|
|
|
279 |
ignored the component ids. As of version 6b, libjpeg interprets the id
|
|
|
280 |
tags, but creates garbage output when they're invalid. We developed a
|
|
|
281 |
<a
|
|
|
282 |
href="http://ghostscript.com/pipermail/gs-code-review/2004-June/004579.html"
|
|
|
283 |
class="offsite">patch
|
|
|
284 |
to libjpeg 6b</a> which makes the decoding more robust. We are not
|
|
|
285 |
aware of anybody maintaining new libjpeg releases, so we include the
|
|
|
286 |
patch here in the hope that people can apply it themselves, and that
|
|
|
287 |
in the event that there is a future libjpeg update, that it will
|
|
|
288 |
include this patch as well. Linux distributions are especially
|
|
|
289 |
encouraged to apply this patch to the system libjpeg package.
|
|
|
290 |
|
|
|
291 |
<p>Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643"
|
|
|
292 |
class="offsite">#686980</a>, July 31, 2003.
|
|
|
293 |
|
|
|
294 |
<hr>
|
|
|
295 |
|
|
|
296 |
<h2><a name="Driver_Issues"></a>Driver Issues.</h2>
|
|
|
297 |
|
|
|
298 |
<h3> [ ] Missing text in landscape mode.</h3>
|
|
|
299 |
Using GSWIN32C.EXE with djet500 to print a file in landscape mode
|
|
|
300 |
on a HP 2000C, the first 3 characters on the left margin are missing.<br>
|
|
|
301 |
When the postscript file is editted to use a larger offset (1st moveto
|
|
|
302 |
parameter), the text appears ok.<br>
|
|
|
303 |
When the postscript file is sent to a printer with a builtin postscript
|
|
|
304 |
interpreter, it prints ok.
|
|
|
305 |
<p>
|
|
|
306 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=206652"
|
|
|
307 |
class="offsite">#206652</a>
|
|
|
308 |
<p><I>
|
|
|
309 |
A possible work around is to send the following
|
|
|
310 |
postscript file to the printer prior to printing the problem
|
|
|
311 |
file. This works but it leaves a .5" margin at the top
|
|
|
312 |
and left which is may be ok for some uses.
|
|
|
313 |
</I>
|
|
|
314 |
<blockquote><pre>
|
|
|
315 |
|
|
|
316 |
%!PS-Adobe-2.0
|
|
|
317 |
% Reset the offset and margins.
|
|
|
318 |
<<
|
|
|
319 |
/PageOffset [-12 -18]
|
|
|
320 |
/Margins [0 0]
|
|
|
321 |
/.HWMargins [0 0 0 0]
|
|
|
322 |
>>
|
|
|
323 |
setpagedevice
|
|
|
324 |
</pre></blockquote>
|
|
|
325 |
|
|
|
326 |
<I>
|
|
|
327 |
This is an instance of the endless struggle with printer margins, especially
|
|
|
328 |
for HP printers. The HP drivers are inconsistent as to whether the user space
|
|
|
329 |
(0,0) should be the physical corner of the page (as it is in PostScript) or
|
|
|
330 |
the corner of the printable area, and if the latterm whether the page should
|
|
|
331 |
be clipped or scaled.
|
|
|
332 |
</I>
|
|
|
333 |
<p>
|
|
|
334 |
|
|
|
335 |
<h3> User request for pdfwrite to convert all colors.</h3>
|
|
|
336 |
|
|
|
337 |
<p>
|
|
|
338 |
Currently, pdfwrite only converts fill/stroke/text/imagemask colors to the
|
|
|
339 |
color space defined by ProcessColorModel, not colors in images. A user
|
|
|
340 |
requested that it convert all colors, including images. (Feature request
|
|
|
341 |
<a href="http://bugs.ghostscript.com/show_bug.cgi?id=485498"
|
|
|
342 |
class="offsite">#485498</a>)
|
|
|
343 |
<p>
|
|
|
344 |
<i>
|
|
|
345 |
ProcessColorModel is a stopgap until pdfwrite handles device-dependent
|
|
|
346 |
vector/text/mask colors properly -- i.e., no longer converts them to a
|
|
|
347 |
single color space. I.e., this request is for a significant enhancement,
|
|
|
348 |
not a bug fix.
|
|
|
349 |
</i>
|
|
|
350 |
|
|
|
351 |
<hr>
|
|
|
352 |
|
|
|
353 |
<h2><a name="Performance"></a>Performance.</h2>
|
|
|
354 |
|
|
|
355 |
<h3>Incremental loading for CIDFontType 2 and TrueType fonts.</h3>
|
|
|
356 |
|
|
|
357 |
Entire TrueType outline data in CIDFontType 2 and TrueType fonts are
|
|
|
358 |
loaded into memory at once. Incremental loading of the outline data is
|
|
|
359 |
indispensable for practical use of Asian fonts.
|
|
|
360 |
<p>
|
|
|
361 |
There is one other type of CID-keyed font that should also be
|
|
|
362 |
loaded incrementally: CFF CIDFontType0, i.e., a CIDFontType 0
|
|
|
363 |
font represented using the compact binary CFF format. This is
|
|
|
364 |
important because this is one of the two variants of Asian OpenType
|
|
|
365 |
fonts (the other is essentially the same as TrueType). Ghostscript
|
|
|
366 |
already supports both of these OpenType variants, but not with
|
|
|
367 |
incremental loading.
|
|
|
368 |
<p>
|
|
|
369 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=223992"
|
|
|
370 |
class="offsite">#223992</a>, November 30, 2000.
|
|
|
371 |
<p><I>
|
|
|
372 |
We suggest that anyone who would like to work on this project
|
|
|
373 |
start by looking at how CIDFontType 0 fonts do incremental loading
|
|
|
374 |
(lib/gs_cidfn.ps and src/zfcid0.c). Probably much of this
|
|
|
375 |
code can be also be used with CIDFontType 2 and TrueType fonts.
|
|
|
376 |
</I>
|
|
|
377 |
|
|
|
378 |
<hr>
|
|
|
379 |
|
|
|
380 |
<h2><a name="Differences_from_Adobe"></a>Differences from Adobe Implementation.</h2>
|
|
|
381 |
|
|
|
382 |
<h3>pdfwrite + TT font => Acrobat 3.x for Windows gives error</h3>
|
|
|
383 |
|
|
|
384 |
Running ps2pdf12 on the file test1.ps produces a PDF on which Acrobat
|
|
|
385 |
3.x for Windows complains about not being able to find or create a
|
|
|
386 |
particular TrueType font that is embedded in the PDF file. However,
|
|
|
387 |
Acrobat 3.x for other platforms, and Acrobat 4.x for all platforms,
|
|
|
388 |
accepts the file.
|
|
|
389 |
<p>
|
|
|
390 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=201955"
|
|
|
391 |
class="offsite">#201955</a>, February 14, 2000.
|
|
|
392 |
|
|
|
393 |
<p><I>
|
|
|
394 |
Since Acrobat 3 is superseded by Acrobat 4 which is available at no
|
|
|
395 |
charge, and the file produced by Ghostscript meets published PDF
|
|
|
396 |
specification, this will most likely be left as is.
|
|
|
397 |
</I>
|
|
|
398 |
|
|
|
399 |
<h3> Inconsistent handling of /Orientation.</h3>
|
|
|
400 |
PLRM says "The dictionary returned by currentpagedevice always
|
|
|
401 |
contains an entry for every parameter supported by the device".
|
|
|
402 |
GS prints both messages in the following program:
|
|
|
403 |
|
|
|
404 |
<blockquote><pre>
|
|
|
405 |
%!
|
|
|
406 |
currentpagedevice /Orientation known not
|
|
|
407 |
{ (This printer does _not_ support Orientation.) =
|
|
|
408 |
}
|
|
|
409 |
if
|
|
|
410 |
<</Orientation 1gt;gt; setpagedevice
|
|
|
411 |
currentpagedevice /Orientation known
|
|
|
412 |
{ (Err... wait... it does.) =
|
|
|
413 |
}
|
|
|
414 |
if
|
|
|
415 |
%%EOF
|
|
|
416 |
</pre></blockquote>
|
|
|
417 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=220967"
|
|
|
418 |
class="offsite">#220967</a>, October 31, 2000.
|
|
|
419 |
<p><I>
|
|
|
420 |
The handling of Orientation is a mess. The PLRM says quite explicitly
|
|
|
421 |
that it is only supported for roll devices, where the page size
|
|
|
422 |
alone doesn't give enough information to decide whether to rotate
|
|
|
423 |
the page.
|
|
|
424 |
<p>
|
|
|
425 |
The reason that Ghostscript accepts it for other devices at all
|
|
|
426 |
is twofold: displays are like roll media in that they don't have
|
|
|
427 |
an inherent orientation, and almost none of the other Ghostscript
|
|
|
428 |
devices actually specify their page sizes. Both of these reasons
|
|
|
429 |
are now poorly motivated: displays should behave like
|
|
|
430 |
portrait-orientation devices (albeit with variable page dimensions),
|
|
|
431 |
rotating the image if the requested page width is greater than
|
|
|
432 |
the height, and now that setpagedevice and the Resource machinery
|
|
|
433 |
are fully implemented, all printer drivers should be updated
|
|
|
434 |
to provide the paper size information. Once these fixes are made
|
|
|
435 |
(which will probably have some repercussions other places in
|
|
|
436 |
the code), Ghostscript will handle Orientation properly.
|
|
|
437 |
<p>
|
|
|
438 |
This should be addressed when the "setpagedevice in C" project is
|
|
|
439 |
completed since part of this will require printer drivers to make
|
|
|
440 |
page size information available to the setpagedevice logic.
|
|
|
441 |
</I>
|
|
|
442 |
|
|
|
443 |
<h3>Filesystem implementation differences.</h3>
|
|
|
444 |
Adobe implementations often treat the filesystem as flat. This means that the
|
|
|
445 |
path separator characters are not handled as special characters in filenames.
|
|
|
446 |
The PLRM states that file names are implementation specific (section 3.8.2)
|
|
|
447 |
and Ghostscript currently implements filenames that conform with the underlying
|
|
|
448 |
operating system as is stated in this section about the %os% device. This
|
|
|
449 |
can result from behaviour that is different from Adobe printer implementations.
|
|
|
450 |
<br><br>
|
|
|
451 |
<I>
|
|
|
452 |
Current implementation is incompatible with most font installers. Installers
|
|
|
453 |
expect that:
|
|
|
454 |
<ul>
|
|
|
455 |
<li>"filenameforall" enumerates all files in all directories using the relative path name.
|
|
|
456 |
Directory names, including . and .. are not enumerated
|
|
|
457 |
</ul>
|
|
|
458 |
<ul>
|
|
|
459 |
<li>characters not supported on the platform are encoded.
|
|
|
460 |
</ul>
|
|
|
461 |
<ul>
|
|
|
462 |
<li>"(w) file" operator creates directories if necessary.
|
|
|
463 |
</ul>
|
|
|
464 |
</I>
|
|
|
465 |
|
|
|
466 |
<h3>Cannot load Adobe's fonts. </h3>
|
|
|
467 |
The following program fails with Adobe fonts:
|
|
|
468 |
|
|
|
469 |
<blockquote><pre>
|
|
|
470 |
(C*)
|
|
|
471 |
{ cvn findfont pop
|
|
|
472 |
} 255 string /Font resourceforall
|
|
|
473 |
</pre></blockquote>
|
|
|
474 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226462"
|
|
|
475 |
class="offsite">#226462</a>, December 20, 2000.
|
|
|
476 |
<p>
|
|
|
477 |
<I>
|
|
|
478 |
The 'findfont' operator and '/Font resourceforall' are very difficult to
|
|
|
479 |
keep consistent, because the same logic algorithms must be implemented
|
|
|
480 |
in two different ways. The problem is likely to be in lib/gs_fonts.ps,
|
|
|
481 |
lib/gs_res.ps, and lib/gs_cidcm.ps.
|
|
|
482 |
</I>
|
|
|
483 |
<h3> There's no %ram% device.</h3>
|
|
|
484 |
GS doesn't have %ram% device reguired on all Level 3 products.
|
|
|
485 |
It is documented in PS Supplement 3010 and 3011 dated August 30, 1999
|
|
|
486 |
<br>
|
|
|
487 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226943"
|
|
|
488 |
class="offsite">#226943</a>, December 27, 2000.
|
|
|
489 |
<p>
|
|
|
490 |
<I>
|
|
|
491 |
This should be implemented using the (disk) file system rather than
|
|
|
492 |
actual RAM, at least initially, since that will be easy.
|
|
|
493 |
<br>
|
|
|
494 |
On Unix, it should be implemented with a directory /tmp/$$/ (where
|
|
|
495 |
$$ is the process id), which Ghostscript should delete when it exits.
|
|
|
496 |
</I>
|
|
|
497 |
|
|
|
498 |
<h3> pdfwrite doesn't recognise the image type by content</h3>
|
|
|
499 |
Currently pdfwrite uses JPEG compression for any 8 bit per component
|
|
|
500 |
images >= 64 pixels in both dimensions.
|
|
|
501 |
<p>
|
|
|
502 |
<I>
|
|
|
503 |
pdfwrite needs to be changed to use a reasonable algorithm for deciding
|
|
|
504 |
between JPEG and Flate compression, probably based on sharp vs. smooth
|
|
|
505 |
color transitions in the image; in case of uncertainty, it should use Flate.
|
|
|
506 |
</I>
|
|
|
507 |
<p>
|
|
|
508 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226391"
|
|
|
509 |
class="offsite">#226391</a>, December 19, 2000.
|
|
|
510 |
<p>
|
|
|
511 |
|
|
|
512 |
|
|
|
513 |
<h3> ps2ascii can't handle incremental fonts</h3>
|
|
|
514 |
ps2ascii fails with rangecheck on incremental fonts.
|
|
|
515 |
Need to recognise incremental fonts and say that incremental
|
|
|
516 |
fonts are impossible to convert to ASCII.
|
|
|
517 |
<p>
|
|
|
518 |
Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=441959"
|
|
|
519 |
class="offsite">#441959</a> keeps good test data for this.
|
|
|
520 |
<p>
|
|
|
521 |
|
|
|
522 |
|
|
|
523 |
<h3> Buffering in input filters</h3>
|
|
|
524 |
|
|
|
525 |
The following program prints differently to stdout on GS and Adobe :
|
|
|
526 |
<p>
|
|
|
527 |
<blockquote><pre>
|
|
|
528 |
%!
|
|
|
529 |
/proc
|
|
|
530 |
{ currentfile =string readline pop
|
|
|
531 |
dup ==
|
|
|
532 |
(%) anchorsearch { pop } if
|
|
|
533 |
} bind def
|
|
|
534 |
/test
|
|
|
535 |
{ //proc /ASCIIHexDecode filter
|
|
|
536 |
3 string readstring pop ==
|
|
|
537 |
} bind def
|
|
|
538 |
|
|
|
539 |
(start) ==
|
|
|
540 |
|
|
|
541 |
test
|
|
|
542 |
%31
|
|
|
543 |
%32
|
|
|
544 |
%33
|
|
|
545 |
%34
|
|
|
546 |
%35
|
|
|
547 |
%36
|
|
|
548 |
%37
|
|
|
549 |
%38
|
|
|
550 |
%39
|
|
|
551 |
|
|
|
552 |
(stop) ==
|
|
|
553 |
|
|
|
554 |
%%EOF
|
|
|
555 |
</pre></blockquote>
|
|
|
556 |
<p>
|
|
|
557 |
<I>
|
|
|
558 |
Adobe fills entire input buffer of ASCIIHexDecode with procedure's output,
|
|
|
559 |
before passing data to ASCIIHexDecode, and without knowledge how much data
|
|
|
560 |
does ASCIIHexDecode want. GS does know the size of data requested,
|
|
|
561 |
so as the procedure is called exact number of times. Thus, GS is more conservative.
|
|
|
562 |
</I>
|
|
|
563 |
<p>
|
|
|
564 |
Anoter useful test to be made by repeating lines %31-%39 hundred times,
|
|
|
565 |
without intermediate empty lines.
|
|
|
566 |
<p>
|
|
|
567 |
|
|
|
568 |
<h3>Improper handling of hybrid fonts.</h3>
|
|
|
569 |
|
|
|
570 |
Hybrid fonts are described in section 9.2 of the "Adobe Type 1 Font Format" book.
|
|
|
571 |
Such fonts cannot load into global VM due to internal usage of <I>save/restore</I>
|
|
|
572 |
(and should do into local VM).
|
|
|
573 |
Hybrid fonts can be recognized by the appearance of the word 'hires' with
|
|
|
574 |
a pre-scan over the font, the same way that .findfontvalue works now.
|
|
|
575 |
|
|
|
576 |
<!-- [2.0 end contents] ==================================================== -->
|
|
|
577 |
|
|
|
578 |
<!-- [3.0 begin visible trailer] =========================================== -->
|
|
|
579 |
<hr>
|
|
|
580 |
|
|
|
581 |
<p>
|
|
|
582 |
<small>Copyright © 2000-2002 artofocode LLC. All rights reserved.</small>
|
|
|
583 |
|
|
|
584 |
<p>
|
|
|
585 |
<small>
|
|
|
586 |
This software is provided AS-IS with no warranty, either express or
|
|
|
587 |
implied.
|
|
|
588 |
|
|
|
589 |
This software is distributed under license and may not be copied,
|
|
|
590 |
modified or distributed except as expressly authorized under the terms
|
|
|
591 |
of the license contained in the file LICENSE in this distribution.
|
|
|
592 |
|
|
|
593 |
For more information about licensing, please refer to
|
|
|
594 |
http://www.ghostscript.com/licensing/. For information on
|
|
|
595 |
commercial licensing, go to http://www.artifex.com/licensing/ or
|
|
|
596 |
contact Artifex Software, Inc., 101 Lucas Valley Road #110,
|
|
|
597 |
San Rafael, CA 94903, U.S.A., +1(415)492-9861.
|
|
|
598 |
</small>
|
|
|
599 |
|
|
|
600 |
<p>
|
|
|
601 |
<small>Ghostscript version 8.53, 20 October 2005
|
|
|
602 |
|
|
|
603 |
<!-- [3.0 end visible trailer] ============================================= -->
|
|
|
604 |
|
|
|
605 |
</body>
|
|
|
606 |
</html>
|