123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606 |
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <html>
- <head>
- <title>Ghostscript Open Issues.</title>
- <!-- $Id: Issues.htm,v 1.52 2005/10/20 19:46:23 ray Exp $ -->
- <link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style">
- </head>
- <body>
- <!-- [1.0 begin visible header] ============================================ -->
- <!-- [1.1 begin headline] ================================================== -->
- <h1>Known limitations and minor bugs.</h1>
- <!-- [1.1 end headline] ==================================================== -->
- <!-- [1.2 begin table of contents] ========================================= -->
- <h2>Table of contents</h2>
- <ul>
- <li><a href="#Known_Limitations">Known Limitations</a>
- <li><a href="#Minor_bugs">Minor bugs</a>
- <li><a href="#Driver_Issues">Specific Driver Issues</a>
- <li><a href="#Performance">Performance</a>
- <li><a href="#Differences_from_Adobe">Differences from Adobe Implementation</a>
- </ul>
- <!-- [1.2 end table of contents] =========================================== -->
- <!-- [1.3 begin hint] ====================================================== -->
- <p>For other information, see the <a href="Projects.htm">Development Projects list
- </a>.
- <!-- [1.3 end hint] ======================================================== -->
- <hr>
- <!-- [1.0 end visible header] ============================================== -->
- <!-- [2.0 begin contents] ================================================== -->
- <p>
- 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.
- <p>
- If you would like to take responsibility for any of these issues, please
- <a href="mailto:raph@artofcode.com">contact us</a>.
- <p>
- Additional comments on implementation approaches or project goals are in
- <I>italic type like this</I>.
- <hr>
- <h2><a name="Known_Limitations"></a>Known Limitations.</h2>
- <h3>bbox device doesn't allow min coords < 0.</h3>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=202735"
- class="offsite">#202735</a>, March 09, 2000.
- <p>
- <I>
- 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.
- <p>
- 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.
- </I>
- <h3>Error messages are too low level and confusing.</h3>
- <p>
- Although technically correct many error messages are confusing for
- end users. Some commonly reported examples are listed below.
- <p>
- When pdfwrite device cannot open the output file it fails with:
- <pre>**** Unable to open the initial device, quitting.</pre>
- When CIDFont-CMap pair required by PDF file is not available GS
- fails with:
- <blockquote><pre>/undefinedresource in --findresource--</pre></blockquote>
- <h3>pswrite device generates low level PostScript.</h3>
- <p>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615165"
- class="offsite">#615165</a>, September 26, 2002.
- <hr>
- <h2><a name="Minor_bugs"></a>Minor Bugs.</h2>
- <h3> Bad JPEG stream in PDF generated when source ends prematurely</h3>
- 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.
- <p>
- One potential workaround is to use -dAutoFilterColorImages=false and
- -dColorImageFilter=/FlateEncode.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=228808"
- class="offsite">#228808</a>, Jan 15, 2000.
- <p>
- <I>
- 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.
- </I>
- <h3> Some attributes of Catalog object are lost during PDF to PDF conversion</h3>
- Dests, OpenAction, URI, PageMode, ViewerPreferences are lost during PDF to PDF
- conversion. Other attributes have not been checked.
- <p>
- <I>
- The loss happens diring PDF interpretation. GS can generate these attributes
- from pdfmark's.
- </I>
- <p>
- March 25, 2001.
- <h3>ps2pdf ignores transfer functions in shaded fill</h3>
- 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.
- <blockquote><pre>
- %!
- <</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
- </pre></blockquote>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=232334"
- class="offsite">#232334</a>, February 14, 2001.
- <h3>ResourceFileName gives wrong result with Font category.</h3>
- The following sequence:
- <blockquote><pre>
- /Font /Category findresource begin
- /CharterBT-Roman 255 string ResourceFileName =
- end
- </pre></blockquote>
- Gives the results:
- <pre>
- /Resource/Font/CharterBT-Roman
- </pre>
- This should be a valid platform specific file name and path such as:
- <pre>
- f:/afpl/fonts/bchr.pfa
- </pre>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=233403"
- class="offsite">#233403</a>, February 21, 2001.
- <h3>GS doesn't handle names of separations with HalftoneType 5.</h3>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643"
- class="offsite">#406643</a>, March 7, 2001.
- <h3> PDF 1.4 images don't deallocate all memory </h3>
- <p>
- 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.
- <h3> Truetype fonts are written with incorrect table checksums </h3>
- <p>
- 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.
- <p>
- 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).
- <p>
- <i>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.</i>
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615620"
- class="offsite">#615620</a>, September 27, 2002.
- <h3> save restore fails from the command line </h3>
- <p>
- 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.
- <p>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=603689"
- class="offsite">#603689</a>, September 2, 2002.
- <h3> Failure to repair incorrect component ids in JPEG images </h3>
- <p>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.
- <p>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
- <a
- href="http://ghostscript.com/pipermail/gs-code-review/2004-June/004579.html"
- class="offsite">patch
- to libjpeg 6b</a> 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.
- <p>Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643"
- class="offsite">#686980</a>, July 31, 2003.
- <hr>
- <h2><a name="Driver_Issues"></a>Driver Issues.</h2>
- <h3> [ ] Missing text in landscape mode.</h3>
- 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.<br>
- When the postscript file is editted to use a larger offset (1st moveto
- parameter), the text appears ok.<br>
- When the postscript file is sent to a printer with a builtin postscript
- interpreter, it prints ok.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=206652"
- class="offsite">#206652</a>
- <p><I>
- 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.
- </I>
- <blockquote><pre>
- %!PS-Adobe-2.0
- % Reset the offset and margins.
- <<
- /PageOffset [-12 -18]
- /Margins [0 0]
- /.HWMargins [0 0 0 0]
- >>
- setpagedevice
- </pre></blockquote>
- <I>
- 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.
- </I>
- <p>
- <h3> User request for pdfwrite to convert all colors.</h3>
- <p>
- 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
- <a href="http://bugs.ghostscript.com/show_bug.cgi?id=485498"
- class="offsite">#485498</a>)
- <p>
- <i>
- 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.
- </i>
- <hr>
- <h2><a name="Performance"></a>Performance.</h2>
- <h3>Incremental loading for CIDFontType 2 and TrueType fonts.</h3>
- 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.
- <p>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=223992"
- class="offsite">#223992</a>, November 30, 2000.
- <p><I>
- 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.
- </I>
- <hr>
- <h2><a name="Differences_from_Adobe"></a>Differences from Adobe Implementation.</h2>
- <h3>pdfwrite + TT font => Acrobat 3.x for Windows gives error</h3>
- 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.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=201955"
- class="offsite">#201955</a>, February 14, 2000.
- <p><I>
- 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.
- </I>
- <h3> Inconsistent handling of /Orientation.</h3>
- 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:
- <blockquote><pre>
- %!
- currentpagedevice /Orientation known not
- { (This printer does _not_ support Orientation.) =
- }
- if
- <</Orientation 1gt;gt; setpagedevice
- currentpagedevice /Orientation known
- { (Err... wait... it does.) =
- }
- if
- %%EOF
- </pre></blockquote>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=220967"
- class="offsite">#220967</a>, October 31, 2000.
- <p><I>
- 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.
- <p>
- 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.
- <p>
- 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.
- </I>
- <h3>Filesystem implementation differences.</h3>
- 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.
- <br><br>
- <I>
- Current implementation is incompatible with most font installers. Installers
- expect that:
- <ul>
- <li>"filenameforall" enumerates all files in all directories using the relative path name.
- Directory names, including . and .. are not enumerated
- </ul>
- <ul>
- <li>characters not supported on the platform are encoded.
- </ul>
- <ul>
- <li>"(w) file" operator creates directories if necessary.
- </ul>
- </I>
- <h3>Cannot load Adobe's fonts. </h3>
- The following program fails with Adobe fonts:
- <blockquote><pre>
- (C*)
- { cvn findfont pop
- } 255 string /Font resourceforall
- </pre></blockquote>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226462"
- class="offsite">#226462</a>, December 20, 2000.
- <p>
- <I>
- 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.
- </I>
- <h3> There's no %ram% device.</h3>
- 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
- <br>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226943"
- class="offsite">#226943</a>, December 27, 2000.
- <p>
- <I>
- This should be implemented using the (disk) file system rather than
- actual RAM, at least initially, since that will be easy.
- <br>
- On Unix, it should be implemented with a directory /tmp/$$/ (where
- $$ is the process id), which Ghostscript should delete when it exits.
- </I>
- <h3> pdfwrite doesn't recognise the image type by content</h3>
- Currently pdfwrite uses JPEG compression for any 8 bit per component
- images >= 64 pixels in both dimensions.
- <p>
- <I>
- 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.
- </I>
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226391"
- class="offsite">#226391</a>, December 19, 2000.
- <p>
- <h3> ps2ascii can't handle incremental fonts</h3>
- ps2ascii fails with rangecheck on incremental fonts.
- Need to recognise incremental fonts and say that incremental
- fonts are impossible to convert to ASCII.
- <p>
- Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=441959"
- class="offsite">#441959</a> keeps good test data for this.
- <p>
- <h3> Buffering in input filters</h3>
- The following program prints differently to stdout on GS and Adobe :
- <p>
- <blockquote><pre>
- %!
- /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
- </pre></blockquote>
- <p>
- <I>
- 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.
- </I>
- <p>
- Anoter useful test to be made by repeating lines %31-%39 hundred times,
- without intermediate empty lines.
- <p>
- <h3>Improper handling of hybrid fonts.</h3>
- Hybrid fonts are described in section 9.2 of the "Adobe Type 1 Font Format" book.
- Such fonts cannot load into global VM due to internal usage of <I>save/restore</I>
- (and should do into local VM).
- Hybrid fonts can be recognized by the appearance of the word 'hires' with
- a pre-scan over the font, the same way that .findfontvalue works now.
- <!-- [2.0 end contents] ==================================================== -->
- <!-- [3.0 begin visible trailer] =========================================== -->
- <hr>
- <p>
- <small>Copyright © 2000-2002 artofocode LLC. All rights reserved.</small>
- <p>
- <small>
- 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 the license contained in the file LICENSE in this distribution.
- For more information about licensing, please refer to
- http://www.ghostscript.com/licensing/. For information on
- commercial licensing, go to http://www.artifex.com/licensing/ or
- contact Artifex Software, Inc., 101 Lucas Valley Road #110,
- San Rafael, CA 94903, U.S.A., +1(415)492-9861.
- </small>
- <p>
- <small>Ghostscript version 8.53, 20 October 2005
- <!-- [3.0 end visible trailer] ============================================= -->
- </body>
- </html>
|