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--
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.
NB. The epswrite device is deprecated as of the 9.12 release, the eps2write device should be used instead which does not suffer these limitations.
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.
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.
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
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.
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.22, 4 October 2017