Known limitations and minor bugs.

Known Limitations
Minor bugs
Specific Driver Issues
Performance
Differences from Adobe Implementation

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.

Error messages are too low level and confusing.

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--

Minor Bugs.

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.

Bad JPEG stream in PDF generated when source ends prematurely

When GS converts the source image to JPEG stream in PDF file and the source data end prematurely, it generates bad JPEG stream. tiff2ps from libtiff distribution often generates such files.

One potential workaround is to use -dAutoFilterColorImages=false and -dColorImageFilter=/FlateEncode.

SourceForge 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.

Some attributes of Catalog object are lost during PDF to PDF conversion

Dests, OpenAction, URI, PageMode, ViewerPreferences are lost during PDF to PDF conversion. Other attributes have not been checked.

The loss happens diring PDF interpretation. GS can generate these attributes from pdfmark's.

March 25, 2001.

ps2pdf ignores transfer functions in shaded fill

ps2pdf ignores transfer functions in the shaded fill but uses them for vector objects. The following sample program has 2 shaded fills and 2 rectangles that should have the same color as the left end of the shaded fill.


      <> >>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

SourceForge Bug #232334, Feb 14, 2001.

ResourceFileName gives wrong result with Font category.

The following sequence:

	/Font /Category findresource begin 
	/CharterBT-Roman 255 string ResourceFileName = 
	end

Gives the results:

        /Resource/Font/CharterBT-Roman

This should be a valid platform specific file name and path such as:

        f:/afpl/fonts/bchr.pfa

SourceForge Bug #233403, Feb 21, 2001.

GS doesn't handle names of separations with HalftoneType 5.

PLRM3 says, that HalftoneType 5 may use user defined names of separations. Neither zht2.c nor cmd_put_drawing_color in gxclpath.c can handle this. GS chooses default halftone component for any non-standard separation name.

SourceForge Bug #406643, Mar 7, 2001.

PDF 1.4 images don't deallocate all memory

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.

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.

Incremental loading for CIDFontType 2 and TrueType fonts.

Entire TrueType outline data in CIDFontType 2 and TrueType fonts are loaded into memory at once. Incremental loading of the outline data is indispensable for practical use of Asian fonts.

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.

SourceForge 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 src/zfcid0.c). Probably much of this code can be also be used with CIDFontType 2 and TrueType fonts.

Differences from Adobe Implementation.

pdfwrite + TT font => Acrobat 3.x for Windows gives error

Running ps2pdf12 on the file test1.ps produces a PDF on which Acrobat 3.x for Windows complains about not being able to find or create a particular TrueType font that is embedded in the PDF file. However, Acrobat 3.x for other platforms, and Acrobat 4.x for all platforms, accepts the file.

SourceForge 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.

Inconsistent handling of /Orientation.

PLRM says "The dictionary returned by currentpagedevice always contains an entry for every parameter supported by the device". GS prints both messages in the following program:

%! 
currentpagedevice /Orientation known not 
{ (This printer does _not_ support Orientation.) = 
} 
if 
<> setpagedevice 
currentpagedevice /Orientation known 
{ (Err... wait... it does.) = 
} 
if 
%%EOF

SourceForge bug #220967, October 31, 2000.

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.

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:
"filenameforall" enumerates all files in all directories using the relative path name. Directory names, including . and .. are not enumerated

characters not supported on the platform are encoded.

"(w) file" operator creates directories if necessary.

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.

pdfwrite doesn't recognise the image type by content

Currently pdfwrite uses JPEG compression for any 8 bit per component images >= 64 pixels in both dimensions.

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.

SourceForge Bug #226391, December 19, 2000.

ps2ascii can't handle incremental fonts

ps2ascii fails with rangecheck on incremental fonts. Need to recognise incremental fonts and say that incremental fonts are impossible to convert to ASCII.

SourceForge Bug #441959 keeps good test data for this.

Buffering in input filters

The following program prints differently to stdout on GS and Adobe :

%!
/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.

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 7.03, 20 October 2001