Known limitations and minor bugs.

Table of contents

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.


Known Limitations.

bbox device doesn't allow min coords < 0.

Adobe eps specification doesn't say that bbox values must be positive, and, for example Adobe Illustrator, can create EPS files with negative bboxes. In such case, Ghostscipt returns zero instead of proper negative number.
SourceForge 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.


Minor Bugs.

kshow doesn't restore currentfont after running proc.

According to the PostScript Language Reference manual, kshow must restore currentfont after running the client's procedure, but Ghostscript doesn't do this. Test case:
%! 
/f1 /Times-Roman findfont 16 scalefont def 
/f2 /Helvetica findfont 24 scalefont def 
100 100 moveto 
/f f1 def 
f setfont 
{ 
    pop pop 
    /f f f1 eq { f2 } { f1 } ifelse def 
    f setfont 
} (abcde) kshow 
showpage quit 
Ghostscript writes the characters in alternating fonts, but Acrobats Distiller writes them all in the original font (f1).
SourceForge Bug #221715, November 5, 2000.

gs-6.31 and gs-6.60 fail running lib/image-qa.ps

Running lib/image-qa.ps with gs-6.31 or gs-6.60 produces an error message.
Type 1 
Stencil 
Mask 
Error: /ioerror in --fileposition-- 
SourceForge Bug #223005, November 20, 2000.

This is an error in the test file, not GS. fileposition correctly throws ioerror when it is used on filtered files.
The test should be written to use .fileposition when running on Ghostscript and enclose fileposition in { } stopped when not. Also for portability to PostScript interpreters without Ghostscript extensions, '=only' should be defined to use '=print' or '='.

PageSize cannot use packedarray

PageSize doesn't accept packed array as an argument if the page size is adjusted, for instance, to the whole number of pixels. The following program
%!
/x 333.33333333 def /y 666.66666666 def

<< /PageSize x y 2 packedarray >> setpagedevice
(pached passed)==    % fails
%EOF
fails with
Error: /configurationerror in --setpagedevice--
Additional information: [/PageSize [333.333344 666.666687]]

Multiple encode filters in a pipeline fail.

The following code fragment should output "3E>". It outputs nothing.
%!PS 
(%stdout) (w) file 
/ASCIIHexEncode filter 
/ASCIIHexEncode filter 
closefile 
SourceForge bug #224134, December 2, 2000.


Driver Issues.

[ ] Missing text in landscape mode.

Using GSWIN32C.EXE with djet500 to print a file in landscape mode on a HP 2000C, the first 3 characters on the left margin are missing.
When the postscript file is editted to use a larger offset (1st moveto parameter), the text appears ok.
When the postscript file is sent to a printer with a builtin postscript interpreter, it prints ok.
SourceForge 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
This is an instance of the endless struggle with printer margins, especially for HP printers. The HP drivers are inconsistent as to whether the user space (0,0) should be the physical corner of the page (as it is in PostScript) or the corner of the printable area, and if the latterm whether the page should be clipped or scaled.


Performance.


Differences from Adobe Implementation.

Filesystem implementation differences.

Adobe implementations often treat the filesystem as flat. This means that the path separator characters are not handled as special characters in filenames. The PLRM states that file names are implementation specific (section 3.8.2) and Ghostscript currently implements filenames that conform with the underlying operating system as is stated in this section about the %os% device. This can result from behaviour that is different from Adobe printer implementations.

Current implementation is incompatible with most font installers. Installers expect that:

Cannot load Adobe's fonts.

The following program fails with Adobe fonts:
(C*) 
{ cvn findfont pop 
} 255 string /Font resourceforall 
SourceForge Bug #226462, December 20, 2000.

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.

There's no %ram% device.

GS doesn't have %ram% device reguired on all Level 3 products. It is documented in PS Supplement 3010 and 3011 dated August 30, 1999
SourceForge Bug #226943, December 27, 2000.

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.


Copyright © 2000 artofocode LLC. All rights reserved.

This file is part of AFPL Ghostscript. See the Aladdin Free Public License (the "License") for full details of the terms of using, copying, modifying, and redistributing AFPL Ghostscript.

Ghostscript version 6.60, 31 December 2000