13ff48bf5SDavid du Colombier<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 23ff48bf5SDavid du Colombier<html> 33ff48bf5SDavid du Colombier<head> 43ff48bf5SDavid du Colombier<title>Ghostscript Open Issues.</title> 5*593dc095SDavid du Colombier<!-- $Id: Issues.htm,v 1.52 2005/10/20 19:46:23 ray Exp $ --> 63ff48bf5SDavid du Colombier<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"> 73ff48bf5SDavid du Colombier</head> 83ff48bf5SDavid du Colombier 93ff48bf5SDavid du Colombier<body> 103ff48bf5SDavid du Colombier<!-- [1.0 begin visible header] ============================================ --> 113ff48bf5SDavid du Colombier 123ff48bf5SDavid du Colombier<!-- [1.1 begin headline] ================================================== --> 133ff48bf5SDavid du Colombier 143ff48bf5SDavid du Colombier<h1>Known limitations and minor bugs.</h1> 153ff48bf5SDavid du Colombier 163ff48bf5SDavid du Colombier<!-- [1.1 end headline] ==================================================== --> 173ff48bf5SDavid du Colombier 183ff48bf5SDavid du Colombier<!-- [1.2 begin table of contents] ========================================= --> 193ff48bf5SDavid du Colombier 203ff48bf5SDavid du Colombier<h2>Table of contents</h2> 213ff48bf5SDavid du Colombier 223ff48bf5SDavid du Colombier<ul> 233ff48bf5SDavid du Colombier<li><a href="#Known_Limitations">Known Limitations</a> 243ff48bf5SDavid du Colombier<li><a href="#Minor_bugs">Minor bugs</a> 253ff48bf5SDavid du Colombier<li><a href="#Driver_Issues">Specific Driver Issues</a> 263ff48bf5SDavid du Colombier<li><a href="#Performance">Performance</a> 273ff48bf5SDavid du Colombier<li><a href="#Differences_from_Adobe">Differences from Adobe Implementation</a> 283ff48bf5SDavid du Colombier</ul> 293ff48bf5SDavid du Colombier 303ff48bf5SDavid du Colombier<!-- [1.2 end table of contents] =========================================== --> 313ff48bf5SDavid du Colombier 323ff48bf5SDavid du Colombier<!-- [1.3 begin hint] ====================================================== --> 333ff48bf5SDavid du Colombier 343ff48bf5SDavid du Colombier<p>For other information, see the <a href="Projects.htm">Development Projects list 353ff48bf5SDavid du Colombier</a>. 363ff48bf5SDavid du Colombier 373ff48bf5SDavid du Colombier<!-- [1.3 end hint] ======================================================== --> 383ff48bf5SDavid du Colombier 393ff48bf5SDavid du Colombier<hr> 403ff48bf5SDavid du Colombier 413ff48bf5SDavid du Colombier<!-- [1.0 end visible header] ============================================== --> 423ff48bf5SDavid du Colombier 433ff48bf5SDavid du Colombier<!-- [2.0 begin contents] ================================================== --> 443ff48bf5SDavid du Colombier 453ff48bf5SDavid du Colombier<p> 463ff48bf5SDavid du ColombierThere are many areas that might make Ghostscript more useful or minor bugs 473ff48bf5SDavid du Colombierthat we would like to investigate and possibly fix, but for which we don't 483ff48bf5SDavid du Colombierhave enough resources. These may or may not be addressed in future releases. 493ff48bf5SDavid du Colombier<p> 503ff48bf5SDavid du ColombierIf you would like to take responsibility for any of these issues, please 513ff48bf5SDavid du Colombier<a href="mailto:raph@artofcode.com">contact us</a>. 523ff48bf5SDavid du Colombier<p> 533ff48bf5SDavid du ColombierAdditional comments on implementation approaches or project goals are in 543ff48bf5SDavid du Colombier<I>italic type like this</I>. 553ff48bf5SDavid du Colombier<hr> 563ff48bf5SDavid du Colombier 573ff48bf5SDavid du Colombier<h2><a name="Known_Limitations"></a>Known Limitations.</h2> 583ff48bf5SDavid du Colombier 593ff48bf5SDavid du Colombier<h3>bbox device doesn't allow min coords < 0.</h3> 603ff48bf5SDavid du ColombierAdobe eps specification doesn't say that bbox values must be positive, 613ff48bf5SDavid du Colombierand, for example Adobe Illustrator, can create EPS files with negative bboxes. 623ff48bf5SDavid du ColombierIn such case, Ghostscipt returns zero instead of proper negative number. 63*593dc095SDavid du Colombier<p> 64*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=202735" 65*593dc095SDavid du Colombierclass="offsite">#202735</a>, March 09, 2000. 663ff48bf5SDavid du Colombier<p> 673ff48bf5SDavid du Colombier<I> 683ff48bf5SDavid du ColombierThis might be able to be fixed by applying a large positive translation to 693ff48bf5SDavid du Colombierthe bbox CTM which would be subtracted from coordinates passed to the target 703ff48bf5SDavid du Colombierdevice as well as from the results the bbox device reports. 713ff48bf5SDavid du Colombier<p> 723ff48bf5SDavid du ColombierIf coordinates for the ImagingBBox[0] and [1] values, then negative 733ff48bf5SDavid du Colombiervalues are handled, but this is not reliable since there are places in 743ff48bf5SDavid du Colombierthe graphics library that depend on first quadrant coordinates. 753ff48bf5SDavid du Colombier</I> 763ff48bf5SDavid du Colombier 773ff48bf5SDavid du Colombier<h3>Error messages are too low level and confusing.</h3> 783ff48bf5SDavid du Colombier 793ff48bf5SDavid du Colombier<p> 803ff48bf5SDavid du ColombierAlthough technically correct many error messages are confusing for 813ff48bf5SDavid du Colombierend users. Some commonly reported examples are listed below. 823ff48bf5SDavid du Colombier 833ff48bf5SDavid du Colombier<p> 843ff48bf5SDavid du ColombierWhen pdfwrite device cannot open the output file it fails with: 853ff48bf5SDavid du Colombier<pre>**** Unable to open the initial device, quitting.</pre> 863ff48bf5SDavid du Colombier 873ff48bf5SDavid du ColombierWhen CIDFont-CMap pair required by PDF file is not available GS 883ff48bf5SDavid du Colombierfails with: 89*593dc095SDavid du Colombier<blockquote><pre>/undefinedresource in --findresource--</pre></blockquote> 903ff48bf5SDavid du Colombier 91*593dc095SDavid du Colombier 92*593dc095SDavid du Colombier<h3>pswrite device generates low level PostScript.</h3> 93*593dc095SDavid du Colombier 94*593dc095SDavid du Colombier<p> 95*593dc095SDavid du Colombierpswrite and epswrite devices reduce everything to path, fill, stroke, clip 96*593dc095SDavid du Colombierimage, and imagemask operations. Although the resulting file 97*593dc095SDavid du Colombierprints OK it produces unsatisfactory results when scaled, 98*593dc095SDavid du Colombierdistilled or imported into graphic editors. 99*593dc095SDavid du ColombierThe file can easily exceed 4GB and hit file size limits 100*593dc095SDavid du Colombierin some applications or operation systems. Handling of big files is 101*593dc095SDavid du Colombierslow. 102*593dc095SDavid du Colombier<p> 103*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615165" 104*593dc095SDavid du Colombierclass="offsite">#615165</a>, September 26, 2002. 1053ff48bf5SDavid du Colombier<hr> 1063ff48bf5SDavid du Colombier<h2><a name="Minor_bugs"></a>Minor Bugs.</h2> 1073ff48bf5SDavid du Colombier 1083ff48bf5SDavid du Colombier<h3> Bad JPEG stream in PDF generated when source ends prematurely</h3> 1093ff48bf5SDavid du ColombierWhen GS converts the source image to JPEG stream in PDF file and the 1103ff48bf5SDavid du Colombiersource data end prematurely, it generates bad JPEG stream. 1113ff48bf5SDavid du Colombiertiff2ps from libtiff distribution often generates such files. 1123ff48bf5SDavid du Colombier<p> 1133ff48bf5SDavid du ColombierOne potential workaround is to use -dAutoFilterColorImages=false and 1143ff48bf5SDavid du Colombier-dColorImageFilter=/FlateEncode. 1153ff48bf5SDavid du Colombier<p> 116*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=228808" 117*593dc095SDavid du Colombierclass="offsite">#228808</a>, Jan 15, 2000. 1183ff48bf5SDavid du Colombier<p> 1193ff48bf5SDavid du Colombier<I> 1203ff48bf5SDavid du ColombierJPEG stream writes image dimensions in JPEG header when the stream is created. 1213ff48bf5SDavid du ColombierWhen the source data end the dimensions are not updated. There may be other 1223ff48bf5SDavid du Colombierproblems too. 1233ff48bf5SDavid du Colombier</I> 1243ff48bf5SDavid du Colombier 1253ff48bf5SDavid du Colombier<h3> Some attributes of Catalog object are lost during PDF to PDF conversion</h3> 1263ff48bf5SDavid du ColombierDests, OpenAction, URI, PageMode, ViewerPreferences are lost during PDF to PDF 1273ff48bf5SDavid du Colombierconversion. Other attributes have not been checked. 1283ff48bf5SDavid du Colombier<p> 1293ff48bf5SDavid du Colombier<I> 1303ff48bf5SDavid du ColombierThe loss happens diring PDF interpretation. GS can generate these attributes 1313ff48bf5SDavid du Colombierfrom pdfmark's. 1323ff48bf5SDavid du Colombier</I> 1333ff48bf5SDavid du Colombier<p> 1343ff48bf5SDavid du ColombierMarch 25, 2001. 1353ff48bf5SDavid du Colombier<h3>ps2pdf ignores transfer functions in shaded fill</h3> 1363ff48bf5SDavid du Colombierps2pdf ignores transfer functions in the shaded fill but 1373ff48bf5SDavid du Colombieruses them for vector objects. The following sample program 1383ff48bf5SDavid du Colombierhas 2 shaded fills and 2 rectangles that should have the 1393ff48bf5SDavid du Colombiersame color as the left end of the shaded fill. 140*593dc095SDavid du Colombier<blockquote><pre> 1413ff48bf5SDavid du Colombier 142*593dc095SDavid du Colombier%! 143*593dc095SDavid du Colombier<</PageSize [612 200] /Policies<</PageSize 1>> >>setpagedevice 1443ff48bf5SDavid du Colombier612 1 scale 1453ff48bf5SDavid du Colombier/grad 1463ff48bf5SDavid du Colombier{ gsave 1473ff48bf5SDavid du Colombier 0 0 1 100 rectclip 148*593dc095SDavid du Colombier << 1493ff48bf5SDavid du Colombier /ColorSpace [/DeviceCMYK] 1503ff48bf5SDavid du Colombier /Domain [0 1] 1513ff48bf5SDavid du Colombier /Coords [0 0 1 0] 1523ff48bf5SDavid du Colombier /Extend [false false] 1533ff48bf5SDavid du Colombier /Function 154*593dc095SDavid du Colombier << /FunctionType 3 1553ff48bf5SDavid du Colombier /Domain [ 0 1] 1563ff48bf5SDavid du Colombier /Functions 157*593dc095SDavid du Colombier [ << 1583ff48bf5SDavid du Colombier /FunctionType 2 1593ff48bf5SDavid du Colombier /N 1 1603ff48bf5SDavid du Colombier /C0 [ 0 0.5 0 0 ] 1613ff48bf5SDavid du Colombier /Domain [ 0 1] 1623ff48bf5SDavid du Colombier /C1 [0.5 0 0 0] 163*593dc095SDavid du Colombier >> ] 1643ff48bf5SDavid du Colombier /Bounds [] 1653ff48bf5SDavid du Colombier /Encode [0 1] 166*593dc095SDavid du Colombier >> 1673ff48bf5SDavid du Colombier /ShadingType 2 168*593dc095SDavid du Colombier >> shfill 1693ff48bf5SDavid du Colombier 1703ff48bf5SDavid du Colombier 0 0.5 0 0 setcmykcolor 1713ff48bf5SDavid du Colombier 0 0 0.1 50 rectfill 1723ff48bf5SDavid du Colombier grestore 1733ff48bf5SDavid du Colombier} def 1743ff48bf5SDavid du Colombier 1753ff48bf5SDavid du Colombiergrad 1763ff48bf5SDavid du Colombier{1 exch 2 div sub} settransfer 1773ff48bf5SDavid du Colombier0 100 translate 1783ff48bf5SDavid du Colombiergrad 1793ff48bf5SDavid du Colombiershowpage 180*593dc095SDavid du Colombier 181*593dc095SDavid du Colombier</pre></blockquote> 182*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=232334" 183*593dc095SDavid du Colombierclass="offsite">#232334</a>, February 14, 2001. 1843ff48bf5SDavid du Colombier 1853ff48bf5SDavid du Colombier<h3>ResourceFileName gives wrong result with Font category.</h3> 1863ff48bf5SDavid du ColombierThe following sequence: 1873ff48bf5SDavid du Colombier 188*593dc095SDavid du Colombier<blockquote><pre> 1893ff48bf5SDavid du Colombier/Font /Category findresource begin 1903ff48bf5SDavid du Colombier/CharterBT-Roman 255 string ResourceFileName = 1913ff48bf5SDavid du Colombierend 192*593dc095SDavid du Colombier</pre></blockquote> 1933ff48bf5SDavid du Colombier 1943ff48bf5SDavid du ColombierGives the results: 1953ff48bf5SDavid du Colombier<pre> 1963ff48bf5SDavid du Colombier /Resource/Font/CharterBT-Roman 1973ff48bf5SDavid du Colombier</pre> 1983ff48bf5SDavid du Colombier 1993ff48bf5SDavid du ColombierThis should be a valid platform specific file name and path such as: 2003ff48bf5SDavid du Colombier<pre> 2013ff48bf5SDavid du Colombier f:/afpl/fonts/bchr.pfa 2023ff48bf5SDavid du Colombier</pre> 203*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=233403" 204*593dc095SDavid du Colombierclass="offsite">#233403</a>, February 21, 2001. 2053ff48bf5SDavid du Colombier<h3>GS doesn't handle names of separations with HalftoneType 5.</h3> 2063ff48bf5SDavid du ColombierPLRM3 says, that HalftoneType 5 may use user defined 2073ff48bf5SDavid du Colombiernames of separations. Neither zht2.c nor cmd_put_drawing_color in 2083ff48bf5SDavid du Colombiergxclpath.c can handle this. GS chooses default halftone component 2093ff48bf5SDavid du Colombierfor any non-standard separation name. 2103ff48bf5SDavid du Colombier<p> 211*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643" 212*593dc095SDavid du Colombierclass="offsite">#406643</a>, March 7, 2001. 2133ff48bf5SDavid du Colombier 2143ff48bf5SDavid du Colombier<h3> PDF 1.4 images don't deallocate all memory </h3> 2153ff48bf5SDavid du Colombier 216*593dc095SDavid du Colombier<p> 2173ff48bf5SDavid du ColombierThe pdf14_begin_typed_image() function in the PDF 1.4 device creates 2183ff48bf5SDavid du Colombiera marking device, but this is not freed on end_image. The garbage 2193ff48bf5SDavid du Colombiercollector will free it, so it's not a real memory leak, but it would 2203ff48bf5SDavid du Colombierstill be nicer to free it explicitly. 2213ff48bf5SDavid du Colombier 222*593dc095SDavid du Colombier<h3> Truetype fonts are written with incorrect table checksums </h3> 223*593dc095SDavid du Colombier 224*593dc095SDavid du Colombier<p> 225*593dc095SDavid du Colombierpsf_write_truetype_data() writes truetype fonts with incorrect 226*593dc095SDavid du Colombierchecksums on most tables. Most truetype interpreters ignore these 227*593dc095SDavid du Colombierso in practice the issue hasn't been a problem. Nevertheless, 228*593dc095SDavid du ColombierGhostscript is embedding off-spec fonts in pdf documents. 229*593dc095SDavid du Colombier 230*593dc095SDavid du Colombier<p> 231*593dc095SDavid du ColombierA complete fix should generate font data in 2 passes: the 232*593dc095SDavid du Colombierfirst pass computes the checksums, the second one 233*593dc095SDavid du Colombierreally writes data. Fonts can be very large, so 234*593dc095SDavid du Colombierbuffering the entire font is not a good solution. The 235*593dc095SDavid du Colombierchecksums can't be modified after the data is written 236*593dc095SDavid du Colombierbecause the output stream may not be positionable 237*593dc095SDavid du Colombier(likely it's a FlateEncode filter). 238*593dc095SDavid du Colombier 239*593dc095SDavid du Colombier<p> 240*593dc095SDavid du Colombier<i>Igor suggests implementing a special encoding filter for 241*593dc095SDavid du Colombierchecksums, and executing the body of 242*593dc095SDavid du Colombierpsf_write_truetype_data twice: first with the checksum 243*593dc095SDavid du Colombierfilter, second with the real output stream. After a TT 244*593dc095SDavid du Colombiertable is completed, its checksum to be taken from the 245*593dc095SDavid du Colombierfilter and to be put into the 'tables' array.</i> 246*593dc095SDavid du Colombier 247*593dc095SDavid du Colombier<p> 248*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=615620" 249*593dc095SDavid du Colombierclass="offsite">#615620</a>, September 27, 2002. 250*593dc095SDavid du Colombier 251*593dc095SDavid du Colombier<h3> save restore fails from the command line </h3> 252*593dc095SDavid du Colombier 253*593dc095SDavid du Colombier<p> 254*593dc095SDavid du ColombierEntering 'save' followed by 'restore' from the interactive 255*593dc095SDavid du ColombierGhostscript prompt (on separate lines) generates an /invalidrestore 256*593dc095SDavid du Colombierexception. It shouldn't. This is a long standing issue. 257*593dc095SDavid du Colombier 258*593dc095SDavid du Colombier<p> 259*593dc095SDavid du ColombierThe problem is that the string that is used 260*593dc095SDavid du Colombierfor command line input by the 'executive' 261*593dc095SDavid du Colombierprocessing still exists when the 'restore' 262*593dc095SDavid du Colombierhappens, but this string is brought into 263*593dc095SDavid du Colombierexistence after the 'save' operation, thus 264*593dc095SDavid du Colombieran causing an invalidrestore. 265*593dc095SDavid du Colombier 266*593dc095SDavid du Colombier<p> 267*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=603689" 268*593dc095SDavid du Colombierclass="offsite">#603689</a>, September 2, 2002. 269*593dc095SDavid du Colombier 270*593dc095SDavid du Colombier<h3> Failure to repair incorrect component ids in JPEG images </h3> 271*593dc095SDavid du Colombier 272*593dc095SDavid du Colombier<p>There are PDF files in the wild containing JPEG images with 273*593dc095SDavid du Colombierincorrect component id tags. Ghostscript currently displays these 274*593dc095SDavid du Colombierfiles incorrectly, but in the past the files displayed fine. The 275*593dc095SDavid du Colombierproblem is not in Ghostscript itself, though, but in the libjpeg 276*593dc095SDavid du Colombierlibrary. 277*593dc095SDavid du Colombier 278*593dc095SDavid du Colombier<p>Behavior changed in recent libjpeg versions; libjpeg version 6a 279*593dc095SDavid du Colombierignored the component ids. As of version 6b, libjpeg interprets the id 280*593dc095SDavid du Colombiertags, but creates garbage output when they're invalid. We developed a 281*593dc095SDavid du Colombier<a 282*593dc095SDavid du Colombierhref="http://ghostscript.com/pipermail/gs-code-review/2004-June/004579.html" 283*593dc095SDavid du Colombierclass="offsite">patch 284*593dc095SDavid du Colombierto libjpeg 6b</a> which makes the decoding more robust. We are not 285*593dc095SDavid du Colombieraware of anybody maintaining new libjpeg releases, so we include the 286*593dc095SDavid du Colombierpatch here in the hope that people can apply it themselves, and that 287*593dc095SDavid du Colombierin the event that there is a future libjpeg update, that it will 288*593dc095SDavid du Colombierinclude this patch as well. Linux distributions are especially 289*593dc095SDavid du Colombierencouraged to apply this patch to the system libjpeg package. 290*593dc095SDavid du Colombier 291*593dc095SDavid du Colombier<p>Bug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=406643" 292*593dc095SDavid du Colombierclass="offsite">#686980</a>, July 31, 2003. 2933ff48bf5SDavid du Colombier 2943ff48bf5SDavid du Colombier<hr> 2953ff48bf5SDavid du Colombier 2963ff48bf5SDavid du Colombier<h2><a name="Driver_Issues"></a>Driver Issues.</h2> 2973ff48bf5SDavid du Colombier 2983ff48bf5SDavid du Colombier<h3> [ ] Missing text in landscape mode.</h3> 2993ff48bf5SDavid du ColombierUsing GSWIN32C.EXE with djet500 to print a file in landscape mode 3003ff48bf5SDavid du Colombieron a HP 2000C, the first 3 characters on the left margin are missing.<br> 3013ff48bf5SDavid du ColombierWhen the postscript file is editted to use a larger offset (1st moveto 3023ff48bf5SDavid du Colombierparameter), the text appears ok.<br> 3033ff48bf5SDavid du ColombierWhen the postscript file is sent to a printer with a builtin postscript 3043ff48bf5SDavid du Colombierinterpreter, it prints ok. 305*593dc095SDavid du Colombier<p> 306*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=206652" 307*593dc095SDavid du Colombierclass="offsite">#206652</a> 3083ff48bf5SDavid du Colombier<p><I> 3093ff48bf5SDavid du ColombierA possible work around is to send the following 3103ff48bf5SDavid du Colombierpostscript file to the printer prior to printing the problem 3113ff48bf5SDavid du Colombierfile. This works but it leaves a .5" margin at the top 3123ff48bf5SDavid du Colombierand left which is may be ok for some uses. 3133ff48bf5SDavid du Colombier</I> 314*593dc095SDavid du Colombier<blockquote><pre> 3153ff48bf5SDavid du Colombier 3163ff48bf5SDavid du Colombier%!PS-Adobe-2.0 3173ff48bf5SDavid du Colombier% Reset the offset and margins. 318*593dc095SDavid du Colombier<< 3193ff48bf5SDavid du Colombier /PageOffset [-12 -18] 3203ff48bf5SDavid du Colombier /Margins [0 0] 3213ff48bf5SDavid du Colombier /.HWMargins [0 0 0 0] 322*593dc095SDavid du Colombier>> 3233ff48bf5SDavid du Colombiersetpagedevice 324*593dc095SDavid du Colombier</pre></blockquote> 3253ff48bf5SDavid du Colombier 3263ff48bf5SDavid du Colombier<I> 3273ff48bf5SDavid du ColombierThis is an instance of the endless struggle with printer margins, especially 3283ff48bf5SDavid du Colombierfor HP printers. The HP drivers are inconsistent as to whether the user space 3293ff48bf5SDavid du Colombier(0,0) should be the physical corner of the page (as it is in PostScript) or 3303ff48bf5SDavid du Colombierthe corner of the printable area, and if the latterm whether the page should 3313ff48bf5SDavid du Colombierbe clipped or scaled. 3323ff48bf5SDavid du Colombier</I> 3333ff48bf5SDavid du Colombier<p> 3343ff48bf5SDavid du Colombier 335*593dc095SDavid du Colombier<h3> User request for pdfwrite to convert all colors.</h3> 336*593dc095SDavid du Colombier 337*593dc095SDavid du Colombier<p> 338*593dc095SDavid du ColombierCurrently, pdfwrite only converts fill/stroke/text/imagemask colors to the 339*593dc095SDavid du Colombiercolor space defined by ProcessColorModel, not colors in images. A user 340*593dc095SDavid du Colombierrequested that it convert all colors, including images. (Feature request 341*593dc095SDavid du Colombier<a href="http://bugs.ghostscript.com/show_bug.cgi?id=485498" 342*593dc095SDavid du Colombierclass="offsite">#485498</a>) 343*593dc095SDavid du Colombier<p> 344*593dc095SDavid du Colombier<i> 345*593dc095SDavid du ColombierProcessColorModel is a stopgap until pdfwrite handles device-dependent 346*593dc095SDavid du Colombiervector/text/mask colors properly -- i.e., no longer converts them to a 347*593dc095SDavid du Colombiersingle color space. I.e., this request is for a significant enhancement, 348*593dc095SDavid du Colombiernot a bug fix. 349*593dc095SDavid du Colombier</i> 350*593dc095SDavid du Colombier 3513ff48bf5SDavid du Colombier<hr> 3523ff48bf5SDavid du Colombier 3533ff48bf5SDavid du Colombier<h2><a name="Performance"></a>Performance.</h2> 3543ff48bf5SDavid du Colombier 3553ff48bf5SDavid du Colombier<h3>Incremental loading for CIDFontType 2 and TrueType fonts.</h3> 3563ff48bf5SDavid du Colombier 3573ff48bf5SDavid du ColombierEntire TrueType outline data in CIDFontType 2 and TrueType fonts are 3583ff48bf5SDavid du Colombierloaded into memory at once. Incremental loading of the outline data is 3593ff48bf5SDavid du Colombierindispensable for practical use of Asian fonts. 3603ff48bf5SDavid du Colombier<p> 3613ff48bf5SDavid du ColombierThere is one other type of CID-keyed font that should also be 3623ff48bf5SDavid du Colombierloaded incrementally: CFF CIDFontType0, i.e., a CIDFontType 0 3633ff48bf5SDavid du Colombierfont represented using the compact binary CFF format. This is 3643ff48bf5SDavid du Colombierimportant because this is one of the two variants of Asian OpenType 3653ff48bf5SDavid du Colombierfonts (the other is essentially the same as TrueType). Ghostscript 3663ff48bf5SDavid du Colombieralready supports both of these OpenType variants, but not with 3673ff48bf5SDavid du Colombierincremental loading. 3683ff48bf5SDavid du Colombier<p> 369*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=223992" 370*593dc095SDavid du Colombierclass="offsite">#223992</a>, November 30, 2000. 3713ff48bf5SDavid du Colombier<p><I> 3723ff48bf5SDavid du ColombierWe suggest that anyone who would like to work on this project 3733ff48bf5SDavid du Colombierstart by looking at how CIDFontType 0 fonts do incremental loading 3743ff48bf5SDavid du Colombier(lib/gs_cidfn.ps and src/zfcid0.c). Probably much of this 3753ff48bf5SDavid du Colombiercode can be also be used with CIDFontType 2 and TrueType fonts. 3763ff48bf5SDavid du Colombier</I> 3773ff48bf5SDavid du Colombier 3783ff48bf5SDavid du Colombier<hr> 3793ff48bf5SDavid du Colombier 3803ff48bf5SDavid du Colombier<h2><a name="Differences_from_Adobe"></a>Differences from Adobe Implementation.</h2> 3813ff48bf5SDavid du Colombier 3823ff48bf5SDavid du Colombier<h3>pdfwrite + TT font => Acrobat 3.x for Windows gives error</h3> 3833ff48bf5SDavid du Colombier 3843ff48bf5SDavid du ColombierRunning ps2pdf12 on the file test1.ps produces a PDF on which Acrobat 3853ff48bf5SDavid du Colombier3.x for Windows complains about not being able to find or create a 3863ff48bf5SDavid du Colombierparticular TrueType font that is embedded in the PDF file. However, 3873ff48bf5SDavid du ColombierAcrobat 3.x for other platforms, and Acrobat 4.x for all platforms, 3883ff48bf5SDavid du Colombieraccepts the file. 3893ff48bf5SDavid du Colombier<p> 390*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=201955" 391*593dc095SDavid du Colombierclass="offsite">#201955</a>, February 14, 2000. 392*593dc095SDavid du Colombier 3933ff48bf5SDavid du Colombier<p><I> 3943ff48bf5SDavid du ColombierSince Acrobat 3 is superseded by Acrobat 4 which is available at no 3953ff48bf5SDavid du Colombiercharge, and the file produced by Ghostscript meets published PDF 3963ff48bf5SDavid du Colombierspecification, this will most likely be left as is. 3973ff48bf5SDavid du Colombier</I> 3983ff48bf5SDavid du Colombier 3993ff48bf5SDavid du Colombier<h3> Inconsistent handling of /Orientation.</h3> 4003ff48bf5SDavid du ColombierPLRM says "The dictionary returned by currentpagedevice always 4013ff48bf5SDavid du Colombiercontains an entry for every parameter supported by the device". 4023ff48bf5SDavid du ColombierGS prints both messages in the following program: 4033ff48bf5SDavid du Colombier 404*593dc095SDavid du Colombier<blockquote><pre> 4053ff48bf5SDavid du Colombier%! 4063ff48bf5SDavid du Colombiercurrentpagedevice /Orientation known not 4073ff48bf5SDavid du Colombier{ (This printer does _not_ support Orientation.) = 4083ff48bf5SDavid du Colombier} 4093ff48bf5SDavid du Colombierif 410*593dc095SDavid du Colombier<</Orientation 1gt;gt; setpagedevice 4113ff48bf5SDavid du Colombiercurrentpagedevice /Orientation known 4123ff48bf5SDavid du Colombier{ (Err... wait... it does.) = 4133ff48bf5SDavid du Colombier} 4143ff48bf5SDavid du Colombierif 4153ff48bf5SDavid du Colombier%%EOF 416*593dc095SDavid du Colombier</pre></blockquote> 417*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=220967" 418*593dc095SDavid du Colombierclass="offsite">#220967</a>, October 31, 2000. 4193ff48bf5SDavid du Colombier<p><I> 4203ff48bf5SDavid du ColombierThe handling of Orientation is a mess. The PLRM says quite explicitly 4213ff48bf5SDavid du Colombierthat it is only supported for roll devices, where the page size 4223ff48bf5SDavid du Colombieralone doesn't give enough information to decide whether to rotate 4233ff48bf5SDavid du Colombierthe page. 4243ff48bf5SDavid du Colombier<p> 4253ff48bf5SDavid du ColombierThe reason that Ghostscript accepts it for other devices at all 4263ff48bf5SDavid du Colombieris twofold: displays are like roll media in that they don't have 4273ff48bf5SDavid du Colombieran inherent orientation, and almost none of the other Ghostscript 4283ff48bf5SDavid du Colombierdevices actually specify their page sizes. Both of these reasons 4293ff48bf5SDavid du Colombierare now poorly motivated: displays should behave like 4303ff48bf5SDavid du Colombierportrait-orientation devices (albeit with variable page dimensions), 4313ff48bf5SDavid du Colombierrotating the image if the requested page width is greater than 4323ff48bf5SDavid du Colombierthe height, and now that setpagedevice and the Resource machinery 4333ff48bf5SDavid du Colombierare fully implemented, all printer drivers should be updated 4343ff48bf5SDavid du Colombierto provide the paper size information. Once these fixes are made 4353ff48bf5SDavid du Colombier(which will probably have some repercussions other places in 4363ff48bf5SDavid du Colombierthe code), Ghostscript will handle Orientation properly. 4373ff48bf5SDavid du Colombier<p> 4383ff48bf5SDavid du ColombierThis should be addressed when the "setpagedevice in C" project is 4393ff48bf5SDavid du Colombiercompleted since part of this will require printer drivers to make 4403ff48bf5SDavid du Colombierpage size information available to the setpagedevice logic. 4413ff48bf5SDavid du Colombier</I> 4423ff48bf5SDavid du Colombier 4433ff48bf5SDavid du Colombier<h3>Filesystem implementation differences.</h3> 4443ff48bf5SDavid du ColombierAdobe implementations often treat the filesystem as flat. This means that the 4453ff48bf5SDavid du Colombierpath separator characters are not handled as special characters in filenames. 4463ff48bf5SDavid du ColombierThe PLRM states that file names are implementation specific (section 3.8.2) 4473ff48bf5SDavid du Colombierand Ghostscript currently implements filenames that conform with the underlying 4483ff48bf5SDavid du Colombieroperating system as is stated in this section about the %os% device. This 4493ff48bf5SDavid du Colombiercan result from behaviour that is different from Adobe printer implementations. 4503ff48bf5SDavid du Colombier<br><br> 4513ff48bf5SDavid du Colombier<I> 4523ff48bf5SDavid du ColombierCurrent implementation is incompatible with most font installers. Installers 4533ff48bf5SDavid du Colombierexpect that: 4543ff48bf5SDavid du Colombier<ul> 455*593dc095SDavid du Colombier<li>"filenameforall" enumerates all files in all directories using the relative path name. 4563ff48bf5SDavid du ColombierDirectory names, including . and .. are not enumerated 4573ff48bf5SDavid du Colombier</ul> 4583ff48bf5SDavid du Colombier<ul> 459*593dc095SDavid du Colombier<li>characters not supported on the platform are encoded. 4603ff48bf5SDavid du Colombier</ul> 4613ff48bf5SDavid du Colombier<ul> 462*593dc095SDavid du Colombier<li>"(w) file" operator creates directories if necessary. 4633ff48bf5SDavid du Colombier</ul> 4643ff48bf5SDavid du Colombier</I> 4653ff48bf5SDavid du Colombier 4663ff48bf5SDavid du Colombier<h3>Cannot load Adobe's fonts. </h3> 4673ff48bf5SDavid du ColombierThe following program fails with Adobe fonts: 4683ff48bf5SDavid du Colombier 469*593dc095SDavid du Colombier<blockquote><pre> 4703ff48bf5SDavid du Colombier(C*) 4713ff48bf5SDavid du Colombier{ cvn findfont pop 4723ff48bf5SDavid du Colombier} 255 string /Font resourceforall 473*593dc095SDavid du Colombier</pre></blockquote> 474*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226462" 475*593dc095SDavid du Colombierclass="offsite">#226462</a>, December 20, 2000. 4763ff48bf5SDavid du Colombier<p> 4773ff48bf5SDavid du Colombier<I> 4783ff48bf5SDavid du ColombierThe 'findfont' operator and '/Font resourceforall' are very difficult to 4793ff48bf5SDavid du Colombierkeep consistent, because the same logic algorithms must be implemented 4803ff48bf5SDavid du Colombierin two different ways. The problem is likely to be in lib/gs_fonts.ps, 4813ff48bf5SDavid du Colombierlib/gs_res.ps, and lib/gs_cidcm.ps. 4823ff48bf5SDavid du Colombier</I> 4833ff48bf5SDavid du Colombier<h3> There's no %ram% device.</h3> 4843ff48bf5SDavid du ColombierGS doesn't have %ram% device reguired on all Level 3 products. 4853ff48bf5SDavid du ColombierIt is documented in PS Supplement 3010 and 3011 dated August 30, 1999 486*593dc095SDavid du Colombier<br> 487*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226943" 488*593dc095SDavid du Colombierclass="offsite">#226943</a>, December 27, 2000. 4893ff48bf5SDavid du Colombier<p> 4903ff48bf5SDavid du Colombier<I> 4913ff48bf5SDavid du ColombierThis should be implemented using the (disk) file system rather than 4923ff48bf5SDavid du Colombieractual RAM, at least initially, since that will be easy. 4933ff48bf5SDavid du Colombier<br> 4943ff48bf5SDavid du ColombierOn Unix, it should be implemented with a directory /tmp/$$/ (where 4953ff48bf5SDavid du Colombier$$ is the process id), which Ghostscript should delete when it exits. 4963ff48bf5SDavid du Colombier</I> 4973ff48bf5SDavid du Colombier 4983ff48bf5SDavid du Colombier<h3> pdfwrite doesn't recognise the image type by content</h3> 4993ff48bf5SDavid du ColombierCurrently pdfwrite uses JPEG compression for any 8 bit per component 5003ff48bf5SDavid du Colombierimages >= 64 pixels in both dimensions. 5013ff48bf5SDavid du Colombier<p> 5023ff48bf5SDavid du Colombier<I> 5033ff48bf5SDavid du Colombierpdfwrite needs to be changed to use a reasonable algorithm for deciding 5043ff48bf5SDavid du Colombierbetween JPEG and Flate compression, probably based on sharp vs. smooth 5053ff48bf5SDavid du Colombiercolor transitions in the image; in case of uncertainty, it should use Flate. 5063ff48bf5SDavid du Colombier</I> 5073ff48bf5SDavid du Colombier<p> 508*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=226391" 509*593dc095SDavid du Colombierclass="offsite">#226391</a>, December 19, 2000. 5103ff48bf5SDavid du Colombier<p> 5113ff48bf5SDavid du Colombier 5123ff48bf5SDavid du Colombier 5133ff48bf5SDavid du Colombier<h3> ps2ascii can't handle incremental fonts</h3> 5143ff48bf5SDavid du Colombierps2ascii fails with rangecheck on incremental fonts. 5153ff48bf5SDavid du ColombierNeed to recognise incremental fonts and say that incremental 5163ff48bf5SDavid du Colombierfonts are impossible to convert to ASCII. 5173ff48bf5SDavid du Colombier<p> 518*593dc095SDavid du ColombierBug <a href="http://bugs.ghostscript.com/show_bug.cgi?id=441959" 519*593dc095SDavid du Colombierclass="offsite">#441959</a> keeps good test data for this. 5203ff48bf5SDavid du Colombier<p> 5213ff48bf5SDavid du Colombier 5223ff48bf5SDavid du Colombier 5233ff48bf5SDavid du Colombier<h3> Buffering in input filters</h3> 5243ff48bf5SDavid du Colombier 5253ff48bf5SDavid du ColombierThe following program prints differently to stdout on GS and Adobe : 5263ff48bf5SDavid du Colombier<p> 527*593dc095SDavid du Colombier<blockquote><pre> 5283ff48bf5SDavid du Colombier%! 5293ff48bf5SDavid du Colombier/proc 5303ff48bf5SDavid du Colombier { currentfile =string readline pop 5313ff48bf5SDavid du Colombier dup == 5323ff48bf5SDavid du Colombier (%) anchorsearch { pop } if 5333ff48bf5SDavid du Colombier } bind def 5343ff48bf5SDavid du Colombier/test 5353ff48bf5SDavid du Colombier { //proc /ASCIIHexDecode filter 5363ff48bf5SDavid du Colombier 3 string readstring pop == 5373ff48bf5SDavid du Colombier } bind def 5383ff48bf5SDavid du Colombier 5393ff48bf5SDavid du Colombier(start) == 5403ff48bf5SDavid du Colombier 5413ff48bf5SDavid du Colombiertest 5423ff48bf5SDavid du Colombier%31 5433ff48bf5SDavid du Colombier%32 5443ff48bf5SDavid du Colombier%33 5453ff48bf5SDavid du Colombier%34 5463ff48bf5SDavid du Colombier%35 5473ff48bf5SDavid du Colombier%36 5483ff48bf5SDavid du Colombier%37 5493ff48bf5SDavid du Colombier%38 5503ff48bf5SDavid du Colombier%39 5513ff48bf5SDavid du Colombier 5523ff48bf5SDavid du Colombier(stop) == 5533ff48bf5SDavid du Colombier 5543ff48bf5SDavid du Colombier%%EOF 555*593dc095SDavid du Colombier</pre></blockquote> 5563ff48bf5SDavid du Colombier<p> 5573ff48bf5SDavid du Colombier<I> 5583ff48bf5SDavid du ColombierAdobe fills entire input buffer of ASCIIHexDecode with procedure's output, 5593ff48bf5SDavid du Colombierbefore passing data to ASCIIHexDecode, and without knowledge how much data 5603ff48bf5SDavid du Colombierdoes ASCIIHexDecode want. GS does know the size of data requested, 5613ff48bf5SDavid du Colombierso as the procedure is called exact number of times. Thus, GS is more conservative. 5623ff48bf5SDavid du Colombier</I> 5633ff48bf5SDavid du Colombier<p> 5643ff48bf5SDavid du ColombierAnoter useful test to be made by repeating lines %31-%39 hundred times, 5653ff48bf5SDavid du Colombierwithout intermediate empty lines. 5663ff48bf5SDavid du Colombier<p> 5673ff48bf5SDavid du Colombier 568*593dc095SDavid du Colombier<h3>Improper handling of hybrid fonts.</h3> 569*593dc095SDavid du Colombier 570*593dc095SDavid du ColombierHybrid fonts are described in section 9.2 of the "Adobe Type 1 Font Format" book. 571*593dc095SDavid du ColombierSuch fonts cannot load into global VM due to internal usage of <I>save/restore</I> 572*593dc095SDavid du Colombier(and should do into local VM). 573*593dc095SDavid du ColombierHybrid fonts can be recognized by the appearance of the word 'hires' with 574*593dc095SDavid du Colombiera pre-scan over the font, the same way that .findfontvalue works now. 5753ff48bf5SDavid du Colombier 5763ff48bf5SDavid du Colombier<!-- [2.0 end contents] ==================================================== --> 5773ff48bf5SDavid du Colombier 5783ff48bf5SDavid du Colombier<!-- [3.0 begin visible trailer] =========================================== --> 5793ff48bf5SDavid du Colombier<hr> 5803ff48bf5SDavid du Colombier 5813ff48bf5SDavid du Colombier<p> 582*593dc095SDavid du Colombier<small>Copyright © 2000-2002 artofocode LLC. All rights reserved.</small> 5833ff48bf5SDavid du Colombier 5843ff48bf5SDavid du Colombier<p> 585*593dc095SDavid du Colombier<small> 586*593dc095SDavid du ColombierThis software is provided AS-IS with no warranty, either express or 587*593dc095SDavid du Colombierimplied. 588*593dc095SDavid du Colombier 589*593dc095SDavid du ColombierThis software is distributed under license and may not be copied, 590*593dc095SDavid du Colombiermodified or distributed except as expressly authorized under the terms 591*593dc095SDavid du Colombierof the license contained in the file LICENSE in this distribution. 592*593dc095SDavid du Colombier 593*593dc095SDavid du ColombierFor more information about licensing, please refer to 594*593dc095SDavid du Colombierhttp://www.ghostscript.com/licensing/. For information on 595*593dc095SDavid du Colombiercommercial licensing, go to http://www.artifex.com/licensing/ or 596*593dc095SDavid du Colombiercontact Artifex Software, Inc., 101 Lucas Valley Road #110, 597*593dc095SDavid du ColombierSan Rafael, CA 94903, U.S.A., +1(415)492-9861. 598*593dc095SDavid du Colombier</small> 5993ff48bf5SDavid du Colombier 6003ff48bf5SDavid du Colombier<p> 601*593dc095SDavid du Colombier<small>Ghostscript version 8.53, 20 October 2005 6023ff48bf5SDavid du Colombier 6033ff48bf5SDavid du Colombier<!-- [3.0 end visible trailer] ============================================= --> 6043ff48bf5SDavid du Colombier 6053ff48bf5SDavid du Colombier</body> 6063ff48bf5SDavid du Colombier</html> 607