For other information, see the Development Projects list .
There are many areas that might make Ghostscript more useful or minor bugs that we would like to investigate and possibly fix, but for which we don't have enough resources. These may or may not be addressed in future releases.
If you would like to take responsibility for any of these issues, please contact us.
Additional comments on implementation approaches or project goals are in italic type like this.
Bug #202735, March 09, 2000.
This might be able to be fixed by applying a large positive translation to the bbox CTM which would be subtracted from coordinates passed to the target device as well as from the results the bbox device reports.
If coordinates for the ImagingBBox[0] and [1] values, then negative values are handled, but this is not reliable since there are places in the graphics library that depend on first quadrant coordinates.
Although technically correct many error messages are confusing for end users. Some commonly reported examples are listed below.
When pdfwrite device cannot open the output file it fails with:
**** Unable to open the initial device, quitting.When CIDFont-CMap pair required by PDF file is not available GS fails with:
/undefinedresource in --findresource--
pswrite and epswrite devices reduce everything to path, fill, stroke, clip image, and imagemask operations. Although the resulting file prints OK it produces unsatisfactory results when scaled, distilled or imported into graphic editors. The file can easily exceed 4GB and hit file size limits in some applications or operation systems. Handling of big files is slow.
Bug #615165, September 26, 2002.
One potential workaround is to use -dAutoFilterColorImages=false and -dColorImageFilter=/FlateEncode.
Bug #228808, Jan 15, 2000.
JPEG stream writes image dimensions in JPEG header when the stream is created. When the source data end the dimensions are not updated. There may be other problems too.
The loss happens diring PDF interpretation. GS can generate these attributes from pdfmark's.
March 25, 2001.
%!
<</PageSize [612 200] /Policies<</PageSize 1>> >>setpagedevice
612 1 scale
/grad
{ gsave
0 0 1 100 rectclip
<<
/ColorSpace [/DeviceCMYK]
/Domain [0 1]
/Coords [0 0 1 0]
/Extend [false false]
/Function
<< /FunctionType 3
/Domain [ 0 1]
/Functions
[ <<
/FunctionType 2
/N 1
/C0 [ 0 0.5 0 0 ]
/Domain [ 0 1]
/C1 [0.5 0 0 0]
>> ]
/Bounds []
/Encode [0 1]
>>
/ShadingType 2
>> shfill
0 0.5 0 0 setcmykcolor
0 0 0.1 50 rectfill
grestore
} def
grad
{1 exch 2 div sub} settransfer
0 100 translate
grad
showpage
Gives the results:/Font /Category findresource begin /CharterBT-Roman 255 string ResourceFileName = end
/Resource/Font/CharterBT-Roman
This should be a valid platform specific file name and path such as:
f:/afpl/fonts/bchr.pfa
Bug #233403, February 21, 2001.
Bug #406643, March 7, 2001.
The pdf14_begin_typed_image() function in the PDF 1.4 device creates a marking device, but this is not freed on end_image. The garbage collector will free it, so it's not a real memory leak, but it would still be nicer to free it explicitly.
psf_write_truetype_data() writes truetype fonts with incorrect checksums on most tables. Most truetype interpreters ignore these so in practice the issue hasn't been a problem. Nevertheless, Ghostscript is embedding off-spec fonts in pdf documents.
A complete fix should generate font data in 2 passes: the first pass computes the checksums, the second one really writes data. Fonts can be very large, so buffering the entire font is not a good solution. The checksums can't be modified after the data is written because the output stream may not be positionable (likely it's a FlateEncode filter).
Igor suggests implementing a special encoding filter for checksums, and executing the body of psf_write_truetype_data twice: first with the checksum filter, second with the real output stream. After a TT table is completed, its checksum to be taken from the filter and to be put into the 'tables' array.
Bug #615620, September 27, 2002.
Entering 'save' followed by 'restore' from the interactive Ghostscript prompt (on separate lines) generates an /invalidrestore exception. It shouldn't. This is a long standing issue.
The problem is that the string that is used for command line input by the 'executive' processing still exists when the 'restore' happens, but this string is brought into existence after the 'save' operation, thus an causing an invalidrestore.
Bug #603689, September 2, 2002.
There are PDF files in the wild containing JPEG images with incorrect component id tags. Ghostscript currently displays these files incorrectly, but in the past the files displayed fine. The problem is not in Ghostscript itself, though, but in the libjpeg library.
Behavior changed in recent libjpeg versions; libjpeg version 6a ignored the component ids. As of version 6b, libjpeg interprets the id tags, but creates garbage output when they're invalid. We developed a patch to libjpeg 6b which makes the decoding more robust. We are not aware of anybody maintaining new libjpeg releases, so we include the patch here in the hope that people can apply it themselves, and that in the event that there is a future libjpeg update, that it will include this patch as well. Linux distributions are especially encouraged to apply this patch to the system libjpeg package.
Bug #686980, July 31, 2003.
Bug #206652
A possible work around is to send the following postscript file to the printer prior to printing the problem file. This works but it leaves a .5" margin at the top and left which is may be ok for some uses.
%!PS-Adobe-2.0
% Reset the offset and margins.
<<
/PageOffset [-12 -18]
/Margins [0 0]
/.HWMargins [0 0 0 0]
>>
setpagedevice
Currently, pdfwrite only converts fill/stroke/text/imagemask colors to the color space defined by ProcessColorModel, not colors in images. A user requested that it convert all colors, including images. (Feature request #485498)
ProcessColorModel is a stopgap until pdfwrite handles device-dependent vector/text/mask colors properly -- i.e., no longer converts them to a single color space. I.e., this request is for a significant enhancement, not a bug fix.
There is one other type of CID-keyed font that should also be loaded incrementally: CFF CIDFontType0, i.e., a CIDFontType 0 font represented using the compact binary CFF format. This is important because this is one of the two variants of Asian OpenType fonts (the other is essentially the same as TrueType). Ghostscript already supports both of these OpenType variants, but not with incremental loading.
Bug #223992, November 30, 2000.
We suggest that anyone who would like to work on this project start by looking at how CIDFontType 0 fonts do incremental loading (lib/gs_cidfn.ps and psi/zfcid0.c). Probably much of this code can be also be used with CIDFontType 2 and TrueType fonts.
Bug #201955, February 14, 2000.
Since Acrobat 3 is superseded by Acrobat 4 which is available at no charge, and the file produced by Ghostscript meets published PDF specification, this will most likely be left as is.
%!
currentpagedevice /Orientation known not
{ (This printer does _not_ support Orientation.) =
}
if
<</Orientation 1gt;gt; setpagedevice
currentpagedevice /Orientation known
{ (Err... wait... it does.) =
}
if
%%EOF
The handling of Orientation is a mess. The PLRM says quite explicitly that it is only supported for roll devices, where the page size alone doesn't give enough information to decide whether to rotate the page.
The reason that Ghostscript accepts it for other devices at all is twofold: displays are like roll media in that they don't have an inherent orientation, and almost none of the other Ghostscript devices actually specify their page sizes. Both of these reasons are now poorly motivated: displays should behave like portrait-orientation devices (albeit with variable page dimensions), rotating the image if the requested page width is greater than the height, and now that setpagedevice and the Resource machinery are fully implemented, all printer drivers should be updated to provide the paper size information. Once these fixes are made (which will probably have some repercussions other places in the code), Ghostscript will handle Orientation properly.
This should be addressed when the "setpagedevice in C" project is completed since part of this will require printer drivers to make page size information available to the setpagedevice logic.
(C*)
{ cvn findfont pop
} 255 string /Font resourceforall
The 'findfont' operator and '/Font resourceforall' are very difficult to keep consistent, because the same logic algorithms must be implemented in two different ways. The problem is likely to be in lib/gs_fonts.ps, lib/gs_res.ps, and lib/gs_cidcm.ps.
This should be implemented using the (disk) file system rather than
actual RAM, at least initially, since that will be easy.
On Unix, it should be implemented with a directory /tmp/$$/ (where
$$ is the process id), which Ghostscript should delete when it exits.
pdfwrite needs to be changed to use a reasonable algorithm for deciding between JPEG and Flate compression, probably based on sharp vs. smooth color transitions in the image; in case of uncertainty, it should use Flate.
Bug #226391, December 19, 2000.
Bug #441959 keeps good test data for this.
%!
/proc
{ currentfile =string readline pop
dup ==
(%) anchorsearch { pop } if
} bind def
/test
{ //proc /ASCIIHexDecode filter
3 string readstring pop ==
} bind def
(start) ==
test
%31
%32
%33
%34
%35
%36
%37
%38
%39
(stop) ==
%%EOF
Adobe fills entire input buffer of ASCIIHexDecode with procedure's output, before passing data to ASCIIHexDecode, and without knowledge how much data does ASCIIHexDecode want. GS does know the size of data requested, so as the procedure is called exact number of times. Thus, GS is more conservative.
Anoter useful test to be made by repeating lines %31-%39 hundred times, without intermediate empty lines.
Copyright © 2000-2006 Artifex Software, Inc. All rights reserved.
This software is provided AS-IS with no warranty, either express or implied. This software is distributed under license and may not be copied, modified or distributed except as expressly authorized under the terms of that license. Refer to licensing information at http://www.artifex.com/ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information.
Ghostscript version 9.01, 7 February 2011