summaryrefslogtreecommitdiff
path: root/Master/xemtex/doc/ghostscript/Issues.htm
diff options
context:
space:
mode:
Diffstat (limited to 'Master/xemtex/doc/ghostscript/Issues.htm')
-rw-r--r--Master/xemtex/doc/ghostscript/Issues.htm502
1 files changed, 502 insertions, 0 deletions
diff --git a/Master/xemtex/doc/ghostscript/Issues.htm b/Master/xemtex/doc/ghostscript/Issues.htm
new file mode 100644
index 00000000000..6285337ecfb
--- /dev/null
+++ b/Master/xemtex/doc/ghostscript/Issues.htm
@@ -0,0 +1,502 @@
+<!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.15.2.13.2.5 2003/05/17 14:39:00 giles 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.
+<br>SourceForge Bug #202735 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:
+<pre>/undefinedresource in --findresource--</pre>
+
+<hr>
+<h2><a name="Minor_bugs"></a>Minor Bugs.</h2>
+
+<h3>PageSize cannot use packedarray</h3>
+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
+<pre>
+%!
+/x 333.33333333 def /y 666.66666666 def
+
+<< /PageSize x y 2 packedarray >> setpagedevice
+(pached passed)== % fails
+%EOF
+</pre>
+fails with
+<pre>
+Error: /configurationerror in --setpagedevice--
+Additional information: [/PageSize [333.333344 666.666687]]
+</pre>
+
+<h3> Multiple encode filters in a pipeline fail.</h3>
+The following code fragment should output "3E>". It outputs nothing.
+<pre>
+%!PS
+(%stdout) (w) file
+/ASCIIHexEncode filter
+/ASCIIHexEncode filter
+closefile
+</pre>
+SourceForge bug #224134, December 2, 2000.
+
+<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>
+SourceForge bug #228808, 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.
+<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>
+SourceForge Bug #232334, Feb 14, 2001.
+
+<h3>ResourceFileName gives wrong result with Font category.</h3>
+The following sequence:
+
+<pre>
+ /Font /Category findresource begin
+ /CharterBT-Roman 255 string ResourceFileName =
+ end
+</pre>
+
+Gives the results:
+<pre>
+ /Resource/Font/CharterBT-Roman
+</pre>
+
+This should be a valid platform specific file name and path such as:
+<pre>
+ f:/fonts/bchr.pfa
+</pre>
+SourceForge Bug #233403, Feb 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>
+SourceForge Bug #406643, Mar 7, 2001.
+
+<h3> PDF 1.4 images don't deallocate all memory </h3>
+
+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> </h3>
+
+<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.
+<br>SourceForge Bug #206652.
+<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>
+<pre>
+
+%!PS-Adobe-2.0
+% Reset the offset and margins.
+<<
+ /PageOffset [-12 -18]
+ /Margins [0 0]
+ /.HWMargins [0 0 0 0]
+>>
+setpagedevice
+</pre>
+
+<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>
+
+<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>
+SourceForge bug #223992, 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>
+SourceForge bug #201955, 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:
+
+<pre>
+%!
+currentpagedevice /Orientation known not
+{ (This printer does _not_ support Orientation.) =
+}
+if
+<</Orientation 1>> setpagedevice
+currentpagedevice /Orientation known
+{ (Err... wait... it does.) =
+}
+if
+%%EOF
+</pre>
+SourceForge bug #220967, 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>
+"filenameforall" enumerates all files in all directories using the relative path name.
+Directory names, including . and .. are not enumerated
+</ul>
+<ul>
+characters not supported on the platform are encoded.
+</ul>
+<ul>
+"(w) file" operator creates directories if necessary.
+</ul>
+</I>
+
+<h3>Cannot load Adobe's fonts. </h3>
+The following program fails with Adobe fonts:
+
+<pre>
+(C*)
+{ cvn findfont pop
+} 255 string /Font resourceforall
+</pre>
+SourceForge Bug #226462, 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>SourceForge Bug #226943, 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>
+SourceForge Bug #226391, 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>
+SourceForge Bug #441959 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>
+<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>
+<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> </h3>
+<p>
+
+
+<!-- [2.0 end contents] ==================================================== -->
+
+<!-- [3.0 begin visible trailer] =========================================== -->
+<hr>
+
+<p>
+<small>Copyright &copy; 2000 artofocode LLC. All rights reserved.</small>
+
+<p>
+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.
+
+<p>
+<small>Ghostscript version 7.07, 17 May 2003
+
+<!-- [3.0 end visible trailer] ============================================= -->
+
+</body>
+</html>