diff options
60 files changed, 3153 insertions, 3803 deletions
diff --git a/gs/base/gscdef.c b/gs/base/gscdef.c index 5e16acb0d..3d65c45a0 100644 --- a/gs/base/gscdef.c +++ b/gs/base/gscdef.c @@ -43,7 +43,7 @@ const char *const gs_productfamily = GS_PRODUCTFAMILY; #ifndef GS_PRODUCT # define GS_PRODUCT\ - GS_PRODUCTFAMILY " SVN PRE-RELEASE" + GS_PRODUCTFAMILY " RELEASE CANDIDATE" #endif const char *const gs_product = GS_PRODUCT; diff --git a/gs/base/version.mak b/gs/base/version.mak index db0e3e0a7..15cde0fa5 100644 --- a/gs/base/version.mak +++ b/gs/base/version.mak @@ -19,7 +19,7 @@ GS_VERSION_MAJOR=9 GS_VERSION_MINOR=02 GS_VERSION_MINOR0=02 # Revision date: year x 10000 + month x 100 + day. -GS_REVISIONDATE=20110207 +GS_REVISIONDATE=20110328 # Derived values GS_VERSION=$(GS_VERSION_MAJOR)$(GS_VERSION_MINOR0) GS_DOT_VERSION=$(GS_VERSION_MAJOR).$(GS_VERSION_MINOR0) diff --git a/gs/doc/API.htm b/gs/doc/API.htm index 59ec05dd5..e28a058bd 100644 --- a/gs/doc/API.htm +++ b/gs/doc/API.htm @@ -760,7 +760,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/C-style.htm b/gs/doc/C-style.htm index 1021c7ae6..b969d777c 100644 --- a/gs/doc/C-style.htm +++ b/gs/doc/C-style.htm @@ -1578,7 +1578,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Commprod.htm b/gs/doc/Commprod.htm index f2aa84766..a965ce861 100644 --- a/gs/doc/Commprod.htm +++ b/gs/doc/Commprod.htm @@ -251,7 +251,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/DLL.htm b/gs/doc/DLL.htm index 1f08c9f99..00adf4b5a 100644 --- a/gs/doc/DLL.htm +++ b/gs/doc/DLL.htm @@ -702,7 +702,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Deprecated.htm b/gs/doc/Deprecated.htm index b822a5213..5d4fd4afa 100644 --- a/gs/doc/Deprecated.htm +++ b/gs/doc/Deprecated.htm @@ -5594,7 +5594,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Details.htm b/gs/doc/Details.htm index 5e0d06d65..5f218e529 100644 --- a/gs/doc/Details.htm +++ b/gs/doc/Details.htm @@ -8,4628 +8,1963 @@ </head> <body> -<p><strong><a name="2011-02-07T141027.833602Z"></a> -2011-02-07T14:10:27.833602Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-28T084948.387061Z"></a> +2011-03-28T08:49:48.387061Z Chris Liddell</strong></p> <blockquote> <pre> -Some updates to the details of the UFST and Freetype related -information. +Reduce duplication of changelog and news by deprecating Changes.htm and +Details#.htm. -Plus adding the warning about Xfonts pending removal. -</pre> -<p>[doc/Make.htm doc/Xfonts.htm]</p> -</blockquote> - -<p><strong><a name="2011-02-05T152932.296497Z"></a> -2011-02-05T15:29:32.296497Z Chris Liddell</strong></p> -<blockquote> -<pre> -As we plan to deprecate Xfonts in a future release, add a -warning message to this effect when an Xfont is used, as follows: +The information will now be in two places only: the highlights summary +in News.htm, and the detailed changes in History#.htm. -"Warning: the Xfonts feature is deprecated and will be removed in a future release." - -No cluster differences expected. +Update related documentation and html links to reflect this change. +CLUSTER_UNTESTED </pre> -<p>[base/gxccman.c]</p> +<p>[doc/Changes.htm doc/Readme.htm doc/Details9.htm doc/Release.htm]</p> </blockquote> -<p><strong><a name="2011-02-05T152725.033646Z"></a> -2011-02-05T15:27:25.033646Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-26T145106.549590Z"></a> +2011-03-26T14:51:06.549590Z Michael Vrhel</strong></p> <blockquote> <pre> -Merge r12117 from the "halftone" branch into trunk, the original commit -comment says: - -Fix bug in bit devices rgb mapping procedure; in the ncomp == 1 case it -was only setting the first component. This was causing indeterminisms in -calling code, which has been giving vastly different timings in Norberts -tests. - -This has apparently been here since revision 3318. - -</pre> -<p>[base/gdevbit.c]</p> +Fix for issue found by Chris where we have a soft mask embedded in a softmask and graphic state pushes and pops occurring. In this case, the soft mask stack that is saved gets out of sync compared to the one in the context state. Use of the stack count can catch the issue and correct it. Also a rename of one of the variables in the pdf14 code to make it easier to debug.</pre> +<p>[base/gdevp14.c base/gdevp14.h]</p> </blockquote> -<p><strong><a name="2011-02-04T155142.379449Z"></a> -2011-02-04T15:51:42.379449Z Robin Watts</strong></p> +<p><strong><a name="2011-03-25T121205.657797Z"></a> +2011-03-25T12:12:05.657797Z Till Kamppeter</strong></p> <blockquote> <pre> -Fix problem with shifting in gsroprun.c. I had systematically got this -wrong throughout the code, but fixed it everywhere except this one -case in an earlier commit. This completes the fix. +Fixes concerning the compatibility of the OpenPrinting Vector ("opvp") +output device with Ghostscript 9.x. -No cluster changes expected. +1. If there is any ICCColor based image in the PostScript input, GS crashes. +2. Fallback when path is too complex for some kinds of printers. This problem + already existed in GS 8.x. -</pre> -<p>[base/gsroprun.c]</p> -</blockquote> - -<p><strong><a name="2011-02-03T123028.178697Z"></a> -2011-02-03T12:30:28.178697Z Chris Liddell</strong></p> -<blockquote> -<pre> -A final tweak to the FAPI/UFST code to keep C compilers -less liberal than gcc happy (specifically Visual C). - -No functional changes. +Thanks to Koji Otani from BBR Inc., Japan. </pre> -<p>[psi/fapiufst.c]</p> +<p>[contrib/opvp/gdevopvp.c]</p> </blockquote> -<p><strong><a name="2011-02-02T182757.905008Z"></a> -2011-02-02T18:27:57.905008Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-25T102206.357287Z"></a> +2011-03-25T10:22:06.357287Z Chris Liddell</strong></p> <blockquote> <pre> -A couple of minor UFST related tweaks to account for differences between -UFST 6.2 and UFST 5.x. +The code was erroneously attempting to get a glyph name for a case where +we already had a glyph index for a Truetype font. -</pre> -<p>[psi/fapiufst.c base/gxfapiu.c]</p> -</blockquote> +Add a check for object type before trying to get a string from a name object. -<p><strong><a name="2011-02-02T171809.939035Z"></a> -2011-02-02T17:18:09.939035Z Ray Johnston</strong></p> -<blockquote> -<pre> -Change Windows makefiles extensively for 64-bit issues: -1. Command line nmake works now for 32-bit build on 64-bit OS -2. 64-bit builds use different directories for objects to allow 32 and - 64 bit builds to be alternated without confusion. 64-bit objects have - '64' suffix to the 32-bit objects which remain in the same places -3. 64-bit binaries are now named uniquely, e.g. gsdll64.dll and gswin64.exe - Binaries coexist in 'bin' directory since names are unique. -4. 'Style' changes to the makefiles to remove the '32' suffix from files - that are not 32-bit specific -- hopefully will prevent future confusion. -Tested with VS 2005 and VS 2008 as well as with GhostPDL.sln (to make sure -the pcl, xps, and language_switch builds don't break. -</pre> -<p>[psi/msvc64.mak psi/gsdll64.def psi/dwsetup.cpp psi/msvc.mak psi/dwmain.c psi/dw64c.def psi/msvc32.mak psi/dwmain64.def psi/dwdll.c base/msvctail.mak psi/dwimg.c]</p> -</blockquote> - -<p><strong><a name="2011-02-02T153453.024741Z"></a> -2011-02-02T15:34:53.024741Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove 4 cases where lines had apparently spurious leading spaces, this seriously -confused nmake and refused to build on Windows. +Bug 692095 No cluster differences expected. -</pre> -<p>[psi/msvc32.mak]</p> -</blockquote> - -<p><strong><a name="2011-02-02T151453.428205Z"></a> -2011-02-02T15:14:53.428205Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (ps2write) : Enable ps2write on PCL - -Bug #691881 "ps2write broken with GhostPCL" - -ps2write formerly required 4 'resource' PostScript files stored on disk in order to -write a PostScript header to the output file. These files have now been converted into -'C' header files and included in the source in earlier revisions. -This commit removes the last barrier to ps2write working with PCL (and other -non-PostScript languages) by removing a disk-based check for opdfread.ps. - -No differences expected. </pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> - -<p><strong><a name="2011-02-02T145537.673202Z"></a> -2011-02-02T14:55:37.673202Z Robin Watts</strong></p> -<blockquote> -<pre> -Add cups files to VS project. This is a very simple, clean patch to the -gs visual studio project file, so (famous last words) can't affect the -cluster build and shouldn't conflict with anyone else. - -</pre> -<p>[ghostscript.vcproj]</p> +<p>[psi/zfapi.c]</p> </blockquote> -<p><strong><a name="2011-02-02T141215.676565Z"></a> -2011-02-02T14:12:15.676565Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-24T172617.397320Z"></a> +2011-03-24T17:26:17.397320Z Chris Liddell</strong></p> <blockquote> <pre> -A set of changes to make it easier to use the UFST with Ghostscript -and to get us closer to having the option of the UFST handling font -types other than the Microtype fonts. - -The UFST build, using the default COMPILE_INITS=1 will now include -the Microtype FCO files in the rom file system along with the other -initialisation files (it does not currently strip out the normal -Postscript fonts in Resource/Fonts), and setup default values for -the various paramters required to have Ghostscript use the -Microtype fonts (these can still be overridden on the command -line). For the build with COMPILE_INITS=0, the default paths -will use the path to the UFST you specify for configure, or -nmake on Windows. - +Resolve build issues with language_switch and UFST. -Included in this revision are changes to prevent the UFST version -5.x (or less) from trying to handle non-Microtype fonts, and allow -it to safely fall back to the Freetype (or a.n.other FAPI plugin). -UFST 6.2 or better will try to handle all fonts types, but this is -not yet reliable. +I had (wrongly) assumed that the PCL/language_switch builds with UFST +and COMPILE_INITS=1 would have the relevant paths correctly setup for +the PS/PDF world to access the Microtype FCOs. It turns out they are +done in an incompatible manner. -Currently, this code only replaces the UFST memory management on -UFST 6.2 and above (this is purely because I haven't time to test -this capability on UFST 5 yet). +So, I've renamed the path variables (in the makefiles) so there isn't +a clash between PCL and PS/PDF, ensured that the variables are correctly +passed through recursive (n)make calls, and tidied up the FAPI options +for the language_switch build. -A further change will be committed shortly to the UFST 5 sources -to force the UFST to use the Ghostscript stream IO instead of the -standard lib file IO on the Windows builds (this has been in place -for the Unix/Linux UFST builds for some time). +Not only does this allow language_switch to build with the UFST, but the +Postscript interpreter does now use FAPI/UFST to access the Microtype fonts +for the built-in fonts, and uses FAPI/Freetype for downloaded fonts. +Bug 692093 +No cluster differences expected. </pre> -<p>[psi/zfapi.c base/Makefile.in Resource/Init/gs_fntem.ps base/configure.ac psi/fapiufst.c base/gxfapiu.c psi/msvc32.mak Resource/Init/gs_fapi.ps]</p> +<p>[/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/main/pcl6_gcc.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p> </blockquote> -<p><strong><a name="2011-02-02T133054.074131Z"></a> -2011-02-02T13:30:54.074131Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-24T042223.459616Z"></a> +2011-03-24T04:22:23.459616Z Michael Vrhel</strong></p> <blockquote> <pre> -The ps2write dependency on the new header files was incorrect (over-enthusiastic -copy and paste error) -</pre> -<p>[base/devs.mak]</p> +Fix for compiler warning.</pre> +<p>[base/gdevp14.h]</p> </blockquote> -<p><strong><a name="2011-02-02T112307.465859Z"></a> -2011-02-02T11:23:07.465859Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-23T213420.429081Z"></a> +2011-03-23T21:34:20.429081Z Michael Vrhel</strong></p> <blockquote> <pre> -Allow building with the system (shared) lcms library. +This commit fixes several issues. -Bug 691644. +Memory leaks in the PDF14 device as well as the separation devices. +Fixes in PDF14 device so the the color encoder and decoder are properly updated if soft masks occur with spot colors. +Proper copying of the devicen parameters to the clist devices in the MT rendering. This was the source of a problem when doing multi-threaded rendering to separation devices. -</pre> -<p>[base/lib.mak base/Makefile.in base/configure.ac]</p> +This fixes bug 692087</pre> +<p>[base/gdevp14.c base/gsicc_cache.c base/gxclutil.c base/gdevpsd.c base/lib.mak base/gdevp14.h base/gxclthrd.c base/gdevtsep.c base/gdevdevn.c base/gxblend.c base/gdevdevn.h]</p> </blockquote> -<p><strong><a name="2011-02-02T092815.868989Z"></a> -2011-02-02T09:28:15.868989Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-21T112417.021832Z"></a> +2011-03-21T11:24:17.021832Z Michael Vrhel</strong></p> <blockquote> <pre> -Remove the check on opdfread.ps from gs_pdfwr.ps as this is no longer shipped as a -PostScript file in /gs/Resource</pre> -<p>[Resource/Init/gs_pdfwr.ps]</p> +Fix for memory leaks in the pdf14 device. These could occur with softmask and graphic state changes as well as when we are going to a tiffsep device. </pre> +<p>[base/gdevp14.c]</p> </blockquote> -<p><strong><a name="2011-02-02T084611.323868Z"></a> -2011-02-02T08:46:11.323868Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-20T014019.345427Z"></a> +2011-03-20T01:40:19.345427Z Michael Vrhel</strong></p> <blockquote> <pre> -Update two make files that had dependencies on opdfread.ps, which has been removed from -the PostScript file system.</pre> -<p>[psi/psromfs.mak base/unixinst.mak]</p> +Fix for bug 692087 crashes. num_bytes - bytes_dropped was ending up negative in cases where the transparency device was reducing the number of colorants compared to the target device (mainly when we had a softmask) which was getting passed into the clist as an unsigned value. Now when this occurs we just use the encoding of the full color value. </pre> +<p>[base/gxclutil.c]</p> </blockquote> -<p><strong><a name="2011-02-02T082743.587977Z"></a> -2011-02-02T08:27:43.587977Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-19T045652.259544Z"></a> +2011-03-19T04:56:52.259544Z Michael Vrhel</strong></p> <blockquote> <pre> -It seems that three of the files removed in revision 12093 are used by devices other -than ps2write. Replacing those files. -</pre> -<p>[Resource/Init/gs_mro_e.ps Resource/Init/gs_agl.ps Resource/Init/gs_mgl_e.ps lib/gs_mro_e.ps lib/gs_agl.ps lib/gs_mgl_e.ps]</p> +A temp fix for bugs 692038 and 692065. The clist devices that are created for the threads now inherit the icc profile from the target device. I need to set things up so that the device profile is no longer reference counted since we could have a race condition problem if the different threads are incrementing and decrementing the count and if the command is not atomic on a particular architecture. The plan will be to no longer ref count the device profile but to have it maintained until the the actual target device is destroyed. There will be a bit of work to do with respect to the pdf14 device, which can have a device profile that is different than the actual target device. That profile can be altered with the transparency group pushes and pops.</pre> +<p>[base/gxclthrd.c]</p> </blockquote> -<p><strong><a name="2011-02-02T081436.361918Z"></a> -2011-02-02T08:14:36.361918Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-19T003237.910024Z"></a> +2011-03-19T00:32:37.910024Z Ray Johnston</strong></p> <blockquote> <pre> -Fix ps2write : Don't depend on the PS file system for resources. - -ps2write needs up to 4 resource files which are normally stored in the PostScript ROM -file system. However on PCL and other languages these resources are (obviously) not -present, so the output is incomplete. - -Move the relevant files from PostScript into 'C' as header files. Remove the files from -the PostScript file system to save ROM file system space. Put the removed files into -the gs/lib folder for safe-keeping. Add the .h files as dependencies for gdevpdfu.c in -the build system so that changes to these files cause a rebuild. +Fix for some strange rendering with PDF 1.7 FTS files when we have shading and transparency +and are both filling and stroking text (Text Rendering modes 2 and 6). Customer 532. -No differences expected. </pre> -<p>[base/opdfread.h Resource/Init/gs_mro_e.ps Resource/Init/gs_agl.ps Resource/Init/gs_mgl_e.ps base/gs_mro_e.h lib/opdfread.ps base/gs_agl.h base/gs_mgl_e.h Resource/Init/opdfread.ps base/gdevpdfu.c lib/gs_mro_e.ps base/devs.mak lib/gs_agl.ps lib/gs_mgl_e.ps]</p> +<p>[Resource/Init/pdf_ops.ps]</p> </blockquote> -<p><strong><a name="2011-02-01T221144.446124Z"></a> -2011-02-01T22:11:44.446124Z Marcos H. Woehrmann</strong></p> +<p><strong><a name="2011-03-18T051608.669973Z"></a> +2011-03-18T05:16:08.669973Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix for missing arch.h when compiling gdevcups.c with parallel make. -</pre> -<p>[base/devs.mak]</p> +Fix so that image_parent_type is properly initialized during clist image reading.</pre> +<p>[base/gsiparm4.h base/gximage1.c base/gximage4.c]</p> </blockquote> -<p><strong><a name="2011-02-01T214627.115736Z"></a> -2011-02-01T21:46:27.115736Z Ray Johnston</strong></p> +<p><strong><a name="2011-03-17T152458.552348Z"></a> +2011-03-17T15:24:58.552348Z Chris Liddell</strong></p> <blockquote> <pre> -Fix for PDF 1.7 fts_09_0910.pdf where the /Font is in an ExtGState instead of -set by the Tf operator. In this case, the font is an indirect reference, not -a font resource name. Reported by customer 532. -</pre> -<p>[Resource/Init/pdf_draw.ps]</p> -</blockquote> +Escape/quote the UFST path settings in the makefile so that the macros +correctly expand to strings. -<p><strong><a name="2011-02-01T170750.035956Z"></a> -2011-02-01T17:07:50.035956Z Chris Liddell</strong></p> -<blockquote> -<pre> -Freetype expects the resolution we supply it to be in -"glyph orientation" - not a problem until we have a -non-square resolution, and rotated glyphs! +Bug 692082 -Bug 691920. +No cluster differences expected +CLUSTER_UNTESTED </pre> -<p>[psi/fapi_ft.c]</p> +<p>[base/Makefile.in]</p> </blockquote> -<p><strong><a name="2011-02-01T140046.378487Z"></a> -2011-02-01T14:00:46.378487Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-17T095453.062174Z"></a> +2011-03-17T09:54:53.062174Z Chris Liddell</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Always write a ToUnicode CMap for TrueType fonts - -Bug #691907 "PDFs with TrueType fonts from Windows PostScript files not searchable" - -Patch from SaGS. - -When choosing whether to embed a ToUnicode CMap, always embed if the font type is -TrueType. This is because TT fonts are always embedded as symbolic, and we now no longer -add Encodings to Symbolic TT fonts (violates spec), which results in PDF files where the -text is unsearchable and cannot be successfully copy/pasted in the absence of a -ToUnicode CMap. +Uncached glyphs were ignoring rendering mode 3, and being imaged +directly to the device - for cached glyphs the decision occurred +in the "show machinery". -It is possible that the ToUnicode CMap is incorrectly generated, but this is no worse -than having no CMap at all. +This wasn't my first choice solution, but all the others I tried +caused problems with later use of a cached glyph (which wasn't +actually cached), or problems with pdfwrite, pswrite or ps2write. -No expected differences since ToUnicode CMaps are not used in rendering. -</pre> -<p>[base/gdevpdtw.c]</p> -</blockquote> - -<p><strong><a name="2011-02-01T115726.132691Z"></a> -2011-02-01T11:57:26.132691Z Robin Watts</strong></p> -<blockquote> -<pre> -Add new 'Profile' configuration to Visual Studio targets. This builds -objects/binaries with debugging symbols enabled, but otherwise full -optimisation. -The changes are entirely within the VS files, except for a few small tweaks -to the MSVC makefile. These changes should mean that it is possible to use -the makefiles in a way that doesn't rely on recursive make calls (even though -we leave the 'debug' targets in for now that do use that). +Bug 692004 -No cluster differences expected or shown in testing. +No cluster differences expected. </pre> -<p>[/trunk/ghostpdl/win32/xps.vcproj ghostscript.vcproj /trunk/ghostpdl/win32/GhostPDL.sln /trunk/ghostpdl/win32/pcl.vcproj /trunk/ghostpdl/win32/svg.vcproj psi/msvc32.mak /trunk/ghostpdl/win32/language_switch.vcproj]</p> -</blockquote> - -<p><strong><a name="2011-02-01T083427.091701Z"></a> -2011-02-01T08:34:27.091701Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : permit symbolic fonts in PDF/A output - -Bug #691877 "Invalid text when converting to PDF/A" - -TrueType fonts were being emitted as non-symbolic when PDF/A output was selected. This -was causing the text to be incorrect, because the fonts actually are symbolic and -Acrobat was unable to apply the correct decoding. - -This will result in more text being unsearchable/copyable but the rendering result is -correct, which is more important. - -No differences expected, PDF/A output not tested on the cluster.</pre> -<p>[base/gdevpdtd.c]</p> +<p>[base/gspaint.c]</p> </blockquote> -<p><strong><a name="2011-01-31T181010.028647Z"></a> -2011-01-31T18:10:10.028647Z Robin Watts</strong></p> +<p><strong><a name="2011-03-17T094116.074991Z"></a> +2011-03-17T09:41:16.074991Z Chris Liddell</strong></p> <blockquote> <pre> -While searching for performance on an ARM based dev board, I developed 2 -new versions of the skip_white_pixels macro. The first uses native int sized -checking, and should be faster on long run matching. I have as yet been unable -to find any files that show this expected speedup. - -The second should be faster on architectures (such as ARM) where the tradeoff -in the test is different (and where pointer arithmetic is cheaper than array -indexing). +Fix some issue where user specified devices didn't get the requisite "$(DD)" +and ".dev" runes added to them. -Both versions are disabled by default until the case for their existence has -been proven, but are committed here to avoid bitrot. +Also, rearrange the "pre-declared" device strings to be more consistent within +configure.ac -No cluster differences expected, as the default code does not change. -</pre> -<p>[base/scf.h]</p> -</blockquote> - -<p><strong><a name="2011-01-31T123210.322306Z"></a> -2011-01-31T12:32:10.322306Z Robin Watts</strong></p> -<blockquote> -<pre> -Tweak to the PxM output code; spot that the output is /dev/null (or nul:) -and avoid saving it. This is a port of code from gdevbit and gdevwts, and is -purely useful for testing/timing/profiling purposes. +Bug 692062 No cluster differences expected. -</pre> -<p>[base/gdevpbm.c]</p> -</blockquote> -<p><strong><a name="2011-01-31T111953.283257Z"></a> -2011-01-31T11:19:53.283257Z Ken Sharp</strong></p> -<blockquote> -<pre> -Revert minor changes accidentally committed in revision 12082. </pre> -<p>[Resource/Init/Fontmap.GS Resource/Init/cidfmap lib/PDFA_def.ps]</p> -</blockquote> - -<p><strong><a name="2011-01-31T111505.175916Z"></a> -2011-01-31T11:15:05.175916Z Ken Sharp</strong></p> -<blockquote> -<pre> -Add the two new make files required for the altered CUPS build, these were accidentally -omitted in revision 12080. -</pre> -<p>[Resource/Init/Fontmap.GS base/lcups.mak Resource/Init/cidfmap lib/PDFA_def.ps base/lcupsi.mak]</p> -</blockquote> - -<p><strong><a name="2011-01-31T110911.349638Z"></a> -2011-01-31T11:09:11.349638Z Ken Sharp</strong></p> -<blockquote> -<pre> -Undo changes to PDFX_def.ps accidentally committed as part of the CPS changes. -</pre> -<p>[lib/PDFX_def.ps]</p> +<p>[base/configure.ac]</p> </blockquote> -<p><strong><a name="2011-01-31T110611.139867Z"></a> -2011-01-31T11:06:11.139867Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-15T175917.340024Z"></a> +2011-03-15T17:59:17.340024Z Robin Watts</strong></p> <blockquote> <pre> -More changes for CUPS, mostly to the build system. - -We now build the CUPS device unconditionally on Windows, using the recently added local -partial copy of the CUPS library sources. This change also builds CUPS on Linux either -using the system shared libraries (if available) or using the same partial copy of the -library sources, if *specifically* directed to use this. +Add special case mem_planar_copy_color_4to1 code for copying bits +from 4 1 bit planes into 1 4 bit chunky plane. -On Windows CUPS is now always built and installed. On Unix systems the behavious is as -follows: +This helps with performance of the plibk device. -./configure cups not installed - no cups device -./configure cups is installed - cups device linked to system cups shared libraries. -./configure --disable-cups - no cups device, regardless of cups libs installed - on system -./configure --with-local-cups - cups device with the partial cups code, regardless of - cups libs installed on system -./configure --with-local-cups --disable-cups results in no cups device. - -No differences expected as the cluster should still build and run with the system -CUPS libraries just as it always has. -</pre> -<p>[base/winlib.mak lib/PDFX_def.ps base/unix-end.mak base/gs.mak cups/cups.mak base/Makefile.in base/configure.ac cups/libs/configlinux.h psi/msvc32.mak base/msvclib.mak base/devs.mak base/msvctail.mak]</p> +No cluster differences expected.</pre> +<p>[base/gdevmpla.c]</p> </blockquote> -<p><strong><a name="2011-01-29T153532.332503Z"></a> -2011-01-29T15:35:32.332503Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-15T083505.386182Z"></a> +2011-03-15T08:35:05.386182Z Ken Sharp</strong></p> <blockquote> <pre> -More changes to the CUPS sources so they will compile on various systems: +Fix (ps2write) : Indexed colour images have incorrect /Decode -language.c - if __APPLE__ is true, includes code which uses what I think is Carbon - Framework calls and structures, but does not #include any of the .h files. - Modified to #undef __APPLE__ to avoid this. +Bug #691924 "Differences in colour with ps2write" -ppd.c - Same problem as for MSVC, the include file string.h seems to prevent the C - string.h being included, and so leaves strchr undefined. Now unconditionally - provide a prototype for strchr. +The problem was due to the opdfread code generating a /Decode for an Indexed colour +space where the value was [0 2^n] and should be [0 ((2^n) - 1)]. This caused the +highest image sample to be mapped to 1 past the end of the samples in the colour space. -localize.c - Another problem with string.h. This doesn't exist on the MSVC build, but - unconditionally providing a prototype fro strcmp doesn't cause an error. +Normally this doesn't matter, because the values are clamped to 'hival' in the Indexed +space. In this case, however, the image was 2 bpp (4 values) but the colour space was +defined as a full 256 indices, with only the first 4 being used. -The code now builds on MSVC, Linux and Mac. Lots of warnings, but I don't propose to -try and deal with those as they would require extensive alterations to the CUPS -sources. +The incorrect Decode caused the image sample value 3 to be looked up as colour space +sample 4, which was set to all 0 (black) causing incorrect colour values. -No differences expected as this code is not yet in use. </pre> -<p>[cups/libs/cups/localize.c cups/libs/cups/language.c cups/libs/cups/ppd.c]</p> +<p>[base/opdfread.h lib/opdfread.ps]</p> </blockquote> -<p><strong><a name="2011-01-28T132120.983748Z"></a> -2011-01-28T13:21:20.983748Z Robin Watts</strong></p> +<p><strong><a name="2011-03-14T154615.599171Z"></a> +2011-03-14T15:46:15.599171Z Robin Watts</strong></p> <blockquote> <pre> -Further rop run optimisations. +Reintroduce commented out PACIFY_VALGRIND definition in gximono.c - without it +the comment makes no sense. - * Add mechanism for dumping ROPs used (including frequency and runlength). -Disabled by default. - * Add special case code for most common rops (invert and xor). - * Correct '1bit colors' code in various cases. +Add new PACIFY_VALGRIND code (and commented out definition) in +gxht_threshold.c. -Cluster pushing shows no differences. +Fix some line endings. + +No real code change, so no cluster differences expected. </pre> -<p>[base/gsroprun.c]</p> +<p>[base/gximono.c base/gxht_thresh.c]</p> </blockquote> -<p><strong><a name="2011-01-28T122737.269985Z"></a> -2011-01-28T12:27:37.269985Z Robin Watts</strong></p> +<p><strong><a name="2011-03-14T151608.036660Z"></a> +2011-03-14T15:16:08.036660Z Robin Watts</strong></p> <blockquote> <pre> -Optimisations to mem_mapped8_copy_mono. Driven initially by a desire to -speed up 100pagemono.pxl on ARM devices, but useful on all architectures. -This work may end up being subsumed by the run_rop work, but is a worthwhile -stepping stone. +Fix an indetermism in the halftoning code. When mapping a y offset into a +row index for a halftone tile, special care needs to be taken when y is +negative. Proof (as if more were needed) that the % operator in C is evil. -On x86 this speeds 100pagemono.pxl in greyscale 600dpi from 4.2 seconds to -3.6seconds. On ARM it shows a definite improvement too, but I don't have -figures to hand. +The command in question was a cutdown version of C306.bin rendered at 600bpi +to pbmraw with dMaxBitmap=10000. -Clusterpush shows no changes. - -</pre> -<p>[base/gdevm8.c]</p> +It now runs into a clist UMR. Will keep looking.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2011-01-27T143346.308935Z"></a> -2011-01-27T14:33:46.308935Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-14T135351.702509Z"></a> +2011-03-14T13:53:51.702509Z Ken Sharp</strong></p> <blockquote> <pre> -Update the CUPS sources so that they can be compiled under Windows. - -1) Remove config.h which was a Linux configure result, replace with configwin.h (from -the CUPS distribution for Windows) and configlinux.h which is config,h renamed. We -will copy and use the correct version at make time. - -2) cups/debug.c guard the use of pthread_mutex so that we don't try to use it if -HAVE_PTHREAD_H is not defined, as the variable will not be declared. Guard use of -cups_debug_filter and cups_filter with a #ifndef WIN32 as these variables are not -defined in a Windows build. Replace gettimeofday with a Windows equivalent when -building on Windows as this function is not available. +Fix (ps2write) : Don't set a default halftone. -3) ppd.c Add a definition of strchr when building for Windows. The use of an include -file called string.h confuses MSVC and it does not include the C string.h which leaves -strchr undefined. +Bug #691923 "Differences in dithered output with ps2write" -4) string.h When defining equivalents to strcasecmp and strncasecmp, also define the -HAVE_* variables so that inclusion order doesn't lead to these being undefined when -we have declared equivalents. +The PDF interpreter emits a setpagdevice between every page of output, in case the +media size has changed. The implementation of setpagedevice resets the halftone to be +the default halftone (106 lpi 45 degree line screen). -5) image-bmp.c Guard the declaration of the BI_* constants with a #ifndef WIN32 as -these are Windows constants and already defined on a Windows build. +This is a problem for ps2write, and potantially pdfwrite, as there is no way to +differentiate between a default halftone set by setpagdevice, and a halftone contained +in the input file. -6) image-colorspace.c Define cbrt() in terms of pow() when WIN32 is set as the MSVC -compiler does not define a cube root function. +To avoid embedding an unhelpful halftone, we now check the device parameter +'/HighLevelDevice' in the setpagedevice implementation, and if it is present and true, +we do not call .setdefaulthalftone. -7) image-tiff.c Guard inclusion of unistd.h when HAVE_LIBTIFF is true as this include -file does not ship with MSVC on Windows. +Also updates documentation on device parameters. - -These have been supplied to the CUPS development group, and at least some of the -problems are likely resolved in a newer version of CUPS. - -No differences expected. +This causes differences on every 1-bit rendering test (ie pkmraw) of the ps2write +output file, so approximately 1300 differences are to be expected. </pre> -<p>[cups/libs/cups/debug.c cups/libs/filter/image-bmp.c cups/libs/cups/string.h cups/libs/configwin.h cups/libs/config.h cups/libs/configlinux.h cups/libs/cups/ppd.c cups/libs/filter/image-tiff.c cups/libs/filter/image-colorspace.c]</p> +<p>[doc/Drivers.htm Resource/Init/gs_setpd.ps]</p> </blockquote> -<p><strong><a name="2011-01-27T130715.912561Z"></a> -2011-01-27T13:07:15.912561Z Tor Andersson</strong></p> +<p><strong><a name="2011-03-14T130003.503443Z"></a> +2011-03-14T13:00:03.503443Z Robin Watts</strong></p> <blockquote> <pre> -Relax version check in JPEG-XR to allow older version HDP and WDP images.</pre> -<p>[jpegxr/cr_parse.c]</p> -</blockquote> +Fix Bug 692064. Tiffscaled device was checking on page print time that the +expected size of the page wouldn't make the page too large to fit in a file. +This code was copied from the tiffgray device (as we render internally in +8bpp). As we output in monochrome however (and may use compression) the +test is in fact bogus, and should simply be removed. We do that here. -<p><strong><a name="2011-01-26T181028.996727Z"></a> -2011-01-26T18:10:28.996727Z Chris Liddell</strong></p> -<blockquote> -<pre> -Fix the message for the new IJS check to read IJS, instead of jpeg! +It's entirely possible that we should be removing the test from the +tiffgray device too - most systems with 32bit longs support large files these +days, and compression may apply here too anyway. I'll leave this until it +becomes an issue though. -</pre> -<p>[base/configure.ac]</p> +No cluster differences expected.</pre> +<p>[base/gdevtsep.c]</p> </blockquote> -<p><strong><a name="2011-01-26T145140.178552Z"></a> -2011-01-26T14:51:40.178552Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-13T115708.378919Z"></a> +2011-03-13T11:57:08.378919Z Ken Sharp</strong></p> <blockquote> <pre> -revert accidentally committed file. -</pre> -<p>[base/jpeg.mak]</p> -</blockquote> +Some updates to the new device parameters. It turned out that the intended parameter +Type32ToUnicode was incorrectly implemented. This should actually have used the +WantsToUnicode parameter, because the code actually controls the processing of +GlyphNames2Unicode tables from Windows PostScript. -<p><strong><a name="2011-01-26T122536.497890Z"></a> -2011-01-26T12:25:36.497890Z Chris Liddell</strong></p> -<blockquote> -<pre> -Allow IJS code to be linked as a library instead of using our distributed source. - -This will permit distributions which include a separately built libijs to link the -the system's libijs. +This means we no longer need the Type32ToUnicode parameter and it has been removed. -Bug 691904 +Added initial documentation of these parameters. +This appears to cause some differences in Bug690829.ps rendered at 300 dpi. +This is a surprise, because the changes should have no effect on devices other than +pdfwrite/ps2write, but the new result is better than the old, so this is a progression. </pre> -<p>[base/winlib.mak base/gdevijs.c base/ijs.mak base/jpeg.mak base/ugcclib.mak base/macosx.mak base/Makefile.in base/configure.ac base/unix-gcc.mak base/unixansi.mak psi/msvc32.mak base/devs.mak]</p> +<p>[Resource/Init/gs_pdfwr.ps base/gdevpdfx.h base/gdevpdfp.c doc/Drivers.htm base/gdevpdfb.h]</p> </blockquote> -<p><strong><a name="2011-01-26T010440.273776Z"></a> -2011-01-26T01:04:40.273776Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-13T012149.785339Z"></a> +2011-03-13T01:21:49.785339Z Ray Johnston</strong></p> <blockquote> <pre> -Old gs assumed TrueType font collections occur only as external resource. -It turned out that PDF can have embedded TrueType collection. So this patch -replaces --setfileposition-- with {... () /SubFileDecode filter flushfile} -for forward search. Bug 691908, customer 870. +Remove spurious debug printout inserted in rev 12141 line 780: + 1 index == 0 index == </pre> -<p>[Resource/Init/gs_ttf.ps]</p> +<p>[Resource/Init/pdf_draw.ps]</p> </blockquote> -<p><strong><a name="2011-01-25T120322.384476Z"></a> -2011-01-25T12:03:22.384476Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-11T192457.067395Z"></a> +2011-03-11T19:24:57.067395Z Ken Sharp</strong></p> <blockquote> <pre> -Add code to define cbrt, strcasecmp and stncasecmp when compiling for Windows, as these -are not present in the MSVC run-time. - -Also alter the initialisation of the gs_cups_device structure. Previously this set three -matrices by including empty braces '{}', but MSVC throws a compilation error on this. -Altered to {0x00} which is not quite the same, but it compiles (with a warning from gcc) -and is no worse than leaving the members uninitialised. +Change the default value for the 'AllowPSRepeat' so that it defaults to allowed instead +of disallowed (doh!) This is important for those devices which don't set the device +parameter. No differences expected. </pre> -<p>[cups/gdevcups.c]</p> -</blockquote> - -<p><strong><a name="2011-01-24T235139.084611Z"></a> -2011-01-24T23:51:39.084611Z Tor Andersson</strong></p> -<blockquote> -<pre> -Add JPEG-XR makefile and library to XPS build.</pre> -<p>[/trunk/ghostpdl/xps/xps.mak /trunk/ghostpdl/xps/xps_msvc.mak base/jpegxr.mak /trunk/ghostpdl/xps/xps_gcc.mak]</p> +<p>[psi/zfunc4.c]</p> </blockquote> -<p><strong><a name="2011-01-24T235123.771340Z"></a> -2011-01-24T23:51:23.771340Z Tor Andersson</strong></p> +<p><strong><a name="2011-03-11T171451.124213Z"></a> +2011-03-11T17:14:51.124213Z Ken Sharp</strong></p> <blockquote> <pre> -Import JPEG-XR reference software. - -ITU-T Rec. T.835 (ex T.JXR-5) | ISO/IEC 29199-5. -JPEG XR reference software 1.8 (September 2009).</pre> -<p>[jpegxr/jpegxr.h jpegxr/io.c jpegxr/jpegxr_pixelformat.c jpegxr/api.c jpegxr/my_getopt-1.5/getopt.h jpegxr/stdint_minimal.h jpegxr/r_strip.c jpegxr/qp.tab.c jpegxr/JPEG-XR.sln jpegxr/cw_emit.c jpegxr/w_strip.c jpegxr/x_strip.c jpegxr/qp.tab.h jpegxr/r_parse.c jpegxr/r_tile_spatial.c jpegxr/app_resource.h jpegxr/Makefile jpegxr/DLL.rc jpegxr/cr_parse.c jpegxr/APP.vcproj jpegxr/w_tile_frequency.c jpegxr/COPYRIGHT.txt jpegxr/jxr_priv.h jpegxr/my_getopt-1.5/LICENSE jpegxr/sample.qp jpegxr jpegxr/file.c jpegxr/my_getopt-1.5/my_getopt.c jpegxr/dllmain.c jpegxr/algo.c jpegxr/file.h jpegxr/my_getopt-1.5/my_getopt.h jpegxr/w_emit.c jpegxr/my_getopt-1.5 jpegxr/dll_resource.h jpegxr/qp_lexor.c jpegxr/README.txt jpegxr/flags.c jpegxr/DLL.vcproj jpegxr/versions-windows.txt jpegxr/jpegxr.c jpegxr/qp_lexor.lex jpegxr/r_tile_frequency.c jpegxr/qp_parse.y jpegxr/w_tile_spatial.c jpegxr/APP.rc jpegxr/init.c]</p> -</blockquote> - -<p><strong><a name="2011-01-24T181640.240500Z"></a> -2011-01-24T18:16:40.240500Z Robin Watts</strong></p> -<blockquote> -<pre> -We want to be able to use planar buffers in a line interleaved format. -Unfortunately, at the moment the planar device is hardcoded to use -contiguous buffers. Fortunately this appears to be a 1 line fix; rather than -calculting raster from the width, we instead calculate it as the difference -between line pointers. - -This does assume that we can always safely read line_ptrs[1], even if we only -have 1 line in the band. (The value is unimportant in this case, but we must -be able to read it without crashing.) - +Remove a #if 0 accidentally left in the commit for revision 12282. Also initialise a +variable, just in case. +No differences expected. </pre> -<p>[base/gdevmpla.c]</p> +<p>[psi/zfunc4.c]</p> </blockquote> -<p><strong><a name="2011-01-24T145630.755196Z"></a> -2011-01-24T14:56:30.755196Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-11T165834.690669Z"></a> +2011-03-11T16:58:34.690669Z Ken Sharp</strong></p> <blockquote> <pre> -Make sure the X11 drivers get removed from the DEVICE_DEVS declaration -if the --enable-dynamic option is give to configure. Also, fix up the -the non shared library builds, so they will still work with ---enable-dynamic (only really useful for debugging). - -Bug 691905. +The final removal of the reliance on testing the device name to influence interpreter +behaviour. -Reorganise and correct the names of the devices specified in -configure.ac so that the options --with-drivers=[FILES,PRINTERS,X11] -actually work. +This tests the /AllowPSRepeat paramter and flags an error if a function tries to use +'repeat' when it is disallowed. -Finally, make the "make debug" compiler options originate from -configure, instead of being hard coded into the Makefile. A first -step in making some of useful debugging features of modern compilers -available when we can. +Still to do: write some documentation on these new parameters. +No differences expected. </pre> -<p>[base/Makefile.in base/configure.ac]</p> -</blockquote> - -<p><strong><a name="2011-01-20T042302.586888Z"></a> -2011-01-20T04:23:02.586888Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Search for 'trailer' harder: at the end and at the beginning of the file. -This helps to recover some more of broken linearized files. -Bug 691894, customer 580. -</pre> -<p>[Resource/Init/pdf_rbld.ps]</p> +<p>[psi/zfunc4.c]</p> </blockquote> -<p><strong><a name="2011-01-19T202554.918598Z"></a> -2011-01-19T20:25:54.918598Z Robin Watts</strong></p> +<p><strong><a name="2011-03-11T151440.609962Z"></a> +2011-03-11T15:14:40.609962Z Chris Liddell</strong></p> <blockquote> <pre> -Revision 12038 revealed a bug in the transparency code; an operation with -a blend mode of 'Normal' and a solid alpha would be allowed to use the -fast stroking code, even though it had transparency in due to being a pattern. - -Here we fix the code to check for transparency. As noted on bug 691900 this -test treats all type 2 patterns as being transparent, so could be improved. - -The cluster differences this gives have been checked and correct the -regressions of revision 12038. - - -</pre> -<p>[base/gdevp14.c base/gstrans.c]</p> -</blockquote> +Add the new third party library directories to the Windows nmake zip file +target. -<p><strong><a name="2011-01-19T180059.394482Z"></a> -2011-01-19T18:00:59.394482Z Robin Watts</strong></p> -<blockquote> -<pre> -Bug 691897 shows a PDF that is much slower when transparency is enabled than -when it is not. The time is primarily spent in the stroke filling code due -to the fact that when transparency is enabled strokes need to be rendered -all at once, rather than segment by segment. This causes the scan conversion -code to have to work much harder. +No cluster differences. -In fact, the code uses solid alpha and "compatible" blend mode for most -strokes, so we would be perfectly safe to use the normal mechanism. The -code attempts to recognise this case already, but was only spotting "Normal" -blend mode and not it's synonym "Compatible". We now roll the two together. +Bug 691944 -Cluster testing shows this produces various differences; none to do with -blending, all to do with different roundings in the positions of the stroked -paths. Bug 690845 is open for this already. +Credit to: Gennadiy Tsarenkov. -</pre> -<p>[base/gdevp14.c base/gstrans.c base/gstparam.h]</p> -</blockquote> +CLUSTER_UNTESTED -<p><strong><a name="2011-01-18T215256.712015Z"></a> -2011-01-18T21:52:56.712015Z regression</strong></p> -<blockquote> -<pre> -Temporarily add 75 dpi pgmraw output to GhostPCL and disable ps2write output to the cluster regressions. </pre> -<p>[toolbin/localcluster/build.pl]</p> +<p>[psi/winint.mak]</p> </blockquote> -<p><strong><a name="2011-01-18T102212.280482Z"></a> -2011-01-18T10:22:12.280482Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-11T150756.095474Z"></a> +2011-03-11T15:07:56.095474Z Chris Liddell</strong></p> <blockquote> <pre> -Resolve some problems with the shared library build on Sparc/Solaris, -with the SunStudio tools. +Rejig the romfs targets so that unix make can follow the dependencies. -Have configure select between the GNUism -soname and the more convetional --h option to set the "internal" name of the shared library. +This should prevent the pointless rebuilding of the romfs C source. -SunStudio 12 has changed the default optimization level option for cc to -be -O3 (previously was -02), which results in Ghostscript crashing. +Bug 692053 No cluster differences expected. -Bug 689490 - </pre> -<p>[base/macosx.mak base/Makefile.in base/configure.ac base/unix-dll.mak base/unix-gcc.mak base/macos-mcp.mak]</p> +<p>[base/lib.mak base/unix-aux.mak]</p> </blockquote> -<p><strong><a name="2011-01-17T213708.425154Z"></a> -2011-01-17T21:37:08.425154Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-11T090424.536166Z"></a> +2011-03-11T09:04:24.536166Z Chris Liddell</strong></p> <blockquote> <pre> -I don't know any version of VC compiler that can compile embedded assembly -code in Luratech JPEG 2000 library. (and other compilers are excluded on -the preprocessor level). So the library is now always compiled with -NO_ASSEMBLY flag. Perhaps, a new version of the library will be better. -</pre> -<p>[psi/msvc32.mak]</p> -</blockquote> +Some (broken) TrueType fonts have out of order loca tables, which can result +in the calculated glyph data lengths being larger than the actual +available glyph data. Normally this does not cause a problem, but if the glyph +in question is in the final bytes of the stream, we encounter an unexpected +end of data condition when creating the glyph data buffer to pass into +Freetype. -<p><strong><a name="2011-01-17T173350.118892Z"></a> -2011-01-17T17:33:50.118892Z Robin Watts</strong></p> -<blockquote> -<pre> -Add code for using run_rops for 8 and 24 bit targets too. Cluster testing shows -that this gives the same results, but limited local testing suggests the setup -costs mean this isn't yet a win. Therefore leaving disabled for now. +So the FAPI interface code will now ignore that error, and adjust the byte +length to correctly reflect the number of bytes available in the buffer. -</pre> -<p>[base/gdevmr8n.c base/gsroprun.c base/gsropt.h]</p> -</blockquote> +It is safe to do this because, in the event we have a genuine out-of-data +condition, Freetype will return an error when it tries to interpret the +glyph outline. -<p><strong><a name="2011-01-17T121139.376205Z"></a> -2011-01-17T12:11:39.376205Z Robin Watts</strong></p> -<blockquote> -<pre> -Remove unused lop_ral definitions, and move pdf14 lop bit down into the freed -space (for neatness). - -No changes expected in cluster. - -</pre> -<p>[base/gsropt.h]</p> -</blockquote> - -<p><strong><a name="2011-01-16T012536.175335Z"></a> -2011-01-16T01:25:36.175335Z Marcos H. Woehrmann</strong></p> -<blockquote> -<pre> -Added missing std.h dependency to gstoptab.c to fix parallel make -under linux. -</pre> -<p>[base/lib.mak]</p> -</blockquote> - -<p><strong><a name="2011-01-15T160130.937666Z"></a> -2011-01-15T16:01:30.937666Z Robin Watts</strong></p> -<blockquote> -<pre> -First commit of new scheme for rop acceleration; offer functions that do -'runs' of rops rather than single rops. This enables us to hide optimised -versions (or even dynamically created code) under a single interface. +Bug 692043 -The current code is only used in 1bpp cases, but is already showing a -signficant speed up, with lots of scope for future optimisations. - -No cluster differences shown. +No cluster differences expected. </pre> -<p>[base/lib.mak base/gsroprun.c base/gsropt.h base/gdevmr1.c]</p> +<p>[psi/fapi_ft.c psi/zfapi.c]</p> </blockquote> -<p><strong><a name="2011-01-15T155350.166886Z"></a> -2011-01-15T15:53:50.166886Z Robin Watts</strong></p> +<p><strong><a name="2011-03-11T054519.450208Z"></a> +2011-03-11T05:45:19.450208Z Alex Cherepanov</strong></p> <blockquote> <pre> -Fix loooong standing bug in rop3_swap_S_T, in that it doesn't actually work. -This shouldn't affect anything as it's not currently used, but WILL be used -in my next commit. - +Fix missing header problem on older versions of MSVC. </pre> <p>[base/gsropt.h]</p> </blockquote> -<p><strong><a name="2011-01-14T185846.405071Z"></a> -2011-01-14T18:58:46.405071Z Henry Stiles</strong></p> +<p><strong><a name="2011-03-11T041539.316030Z"></a> +2011-03-11T04:15:39.316030Z Michael Vrhel</strong></p> <blockquote> <pre> -Bracket off gs_debug_c with #ifdef DEBUG so it is not called in -production builds. - -</pre> -<p>[base/gxht.c base/gxclimag.c base/gxttfb.c base/gxpcmap.c base/gxccman.c base/gsfcmap1.c base/gspaint.c]</p> +A reorganization of the halftone code in preparation of doing thresholding of color images. This basically pulls out some code pieces that will be shared in all the image thresholding cases. No differences expected (or seen in the cluster push).</pre> +<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gxicolor.c base/gxht_thresh.c]</p> </blockquote> -<p><strong><a name="2011-01-14T165647.376046Z"></a> -2011-01-14T16:56:47.376046Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-10T173138.501799Z"></a> +2011-03-10T17:31:38.501799Z Robin Watts</strong></p> <blockquote> <pre> -Changes to the Unix configure based builds to tidy up specifying -subsets of output devices. - -Some devices were always being included regardless of the options -given to configure, resolved by tidying up the macro expansions -in Makefile.in done by the configure script. - -Also the page device and clist device are effectively required by -all configurations, so those are now included in the core build. - -Finally, the contrib/gomni.c driver relied on two functions in -base/gdevbmpc.c which is an optional driver, so configuring -the Omni driver to be built it, and bmp16 not would result -in undefined symbols. contrib/gomni.c now has its own -equivalents of those functions. - -The bbox device remains as the ultimate "fallback" device. - -Bug 689546 +I missed one change in commit 12274. The detection of chunky modes should +look at num_planes being <= 1, not == 1. +I tested this locally and then clearly missed it when cluster pushing. </pre> -<p>[base/lib.mak contrib/gomni.c base/Makefile.in base/configure.ac base/devs.mak]</p> +<p>[base/gdevdrop.c]</p> </blockquote> -<p><strong><a name="2011-01-13T161939.522851Z"></a> -2011-01-13T16:19:39.522851Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-10T165615.200283Z"></a> +2011-03-10T16:56:15.200283Z Robin Watts</strong></p> <blockquote> <pre> -Remove the bogus C++ requirement in the copy of Jasper we -ship with Ghostscript by recreating the autotools related -files for Jasper. - -I can't be sure, but it seems that a bug in one of the -autotools originally used for our Jasper had a bug which -resulted in C++ being misidentified as a required, -rather than optional, feature of the build environment. - -Bug 691563. - -No cluster differences expected. +Planar device is broken w.r.t rops in a cmyk space - this commit fixes it. +The planar memory device sets itself to use gx_default_strip_copy_rop +rather than mem_strip_copy_rop. mem_strip_copy_rop knows that rops on +cmyk pixels should actually convert to rgb, perform the rop, and convert +back again, but doesn't know how to convert the results back when it's in +planar mode. gs_default_strip_copy_rop can cope with planar mode, but doesn't +know to convert to rgb first. +The first fix included here is to extend mem_strip_copy_rop to know how to +write back to planar format, and then to make the planar memory device use +mem_strip_copy_rop. -</pre> -<p>[jasper/src/libjasper/jpc/Makefile.in jasper/src/libjasper/bmp/Makefile.in jasper/configure.ac jasper/src/libjasper/jpg/Makefile.in jasper/src/appl/Makefile.in jasper/src/libjasper/include/Makefile.in jasper/src/libjasper/ras/Makefile.in jasper/src/Makefile.in jasper/aclocal.m4 jasper/src/libjasper/pnm/Makefile.in jasper/src/libjasper/jp2/Makefile.in jasper/configure jasper/src/msvc/Makefile.in jasper/src/libjasper/pgx/Makefile.in jasper/Makefile.in jasper/src/libjasper/Makefile.in jasper/src/libjasper/include/jasper/Makefile.in jasper/src/libjasper/base/Makefile.in jasper/src/libjasper/mif/Makefile.in]</p> -</blockquote> - -<p><strong><a name="2011-01-13T143733.986698Z"></a> -2011-01-13T14:37:33.986698Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix Bug 689698 by prefixing scan_token (and other externally exported -scanning related symbols) by gs_. +This then exposes various flaws in mem_strip_copy_rop, including the fact +that it relies on being able to set the offset in get_bits calls when this +is sometimes not possible. We therefore fix the code to manage offsets +by explicitly updating them. -No changes in cluster testing (other than 1 timeout, and 2 indeterminisms). +Also, the raster used in mem_strip_copy_rop was incorrect - we use the +correct one and get much better results. +No cluster differences expected as the planar device is not tested. </pre> -<p>[psi/ztoken.c psi/ztype.c psi/imain.c psi/iscan.c psi/itoken.h psi/ziodev.c psi/interp.c psi/iscan.h psi/imainarg.c]</p> +<p>[base/gdevdrop.c base/gdevmpla.c]</p> </blockquote> -<p><strong><a name="2011-01-12T211153.461044Z"></a> -2011-01-12T21:11:53.461044Z Robin Watts</strong></p> +<p><strong><a name="2011-03-10T164220.394889Z"></a> +2011-03-10T16:42:20.394889Z Robin Watts</strong></p> <blockquote> <pre> -Fix Bug 691682 - cryptic error messages when misspecifying compression type -for tiff devices. +The routines in gdevplib.c intended to map colors in cmyk form back to rgb +were incorrect. Fixed here. -This patch makes the tiff devices take heed of errors propogated up from the -tiff library. This means we'll now drop out at the first error rather than -carry on through and give a broken file at the end silently. +No differences expected as this files isn't linked in by default. -Also, we output a more helpful error message in the case where the -compression type is misselected. +CLUSTER_UNTESTED -Cluster testing shows no changes. </pre> -<p>[base/gdevtifs.c]</p> +<p>[base/gdevplib.c]</p> </blockquote> -<p><strong><a name="2011-01-11T213354.972732Z"></a> -2011-01-11T21:33:54.972732Z Michael Vrhel</strong></p> +<p><strong><a name="2011-03-10T162704.913812Z"></a> +2011-03-10T16:27:04.913812Z Robin Watts</strong></p> <blockquote> <pre> -Fix for a number of issues found by Ray with the halftone creation tool. +Remove the buffer blanking done in gximono.c. Previously removing this would +have caused indeterminisms. With the additional fix in here to limit +offset_bits to dest_width, however, we should get stable results. -These include a crash for a divide by zero in the gcd function (caused failure at 0 degree screen generation) -Fix so that the Holladay screen is no longer created as an output option. -Fix in ppm output header. -Fix in how the lpi is selected. -Fix for when we have a screen that has essentially one dot (also caused a crash). -Addition of a ReadMe. +This gives various differences in output (81 in pcl, presumably more in PDF +and PS). Bmpcmp of the pcl ones shows them as all progressions. -A lot more testing is needed, in particular, the dithering of the dots in the macro-screens needs additional testing and the relationship between the desired number of quantization levels and the size of the screen needs to be properly computed. There is a list of features that need to be added described in the ReadMe. </pre> -<p>[toolbin/color/halftone/halfttoning/halfttoning.vcproj toolbin/color/halftone/README toolbin/color/halftone/halfttoning/halftone.c]</p> -</blockquote> - -<p><strong><a name="2011-01-11T011759.815496Z"></a> -2011-01-11T01:17:59.815496Z Ray Johnston</strong></p> -<blockquote> -<pre> -Add output modes for PostScript HalftoneType 3 threshold arrays (-ps) and -PPM files (-ppm) that have the width in the file rather than only encoded -in the filename. The -ppm mode is untested and marginally useful. - -The -ps mode was tested (on Windoze) with: - -toolbin/color/halftone/Debug/halfttoning.exe -ps -r 300 -l 23 -a 45 - -gswin32c -r300 -dDisplayFormat=16#20102 -c "(Screen_Holladay_Shift10_20x10.ps) \ - run sethalftone (examples/tiger.eps) run" - -The result doesn't look very good, but at least it runs and we can examine -the problems. -</pre> -<p>[toolbin/color/halftone/halfttoning/halftone.c]</p> -</blockquote> - -<p><strong><a name="2011-01-11T004920.559732Z"></a> -2011-01-11T00:49:20.559732Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Hopefully a fix for indeterminism introduced in rev 12005. The source of this was that the cups and psdcmyk device are now using the older slower color image rendering function due to the fact that they have non-standard color mapping procedures. Missing parenthesis were introduced when the ICC branch was merged into the trunk which was the source of the issue. This was causing a check for color range mask testing even when the image was not a type 4.</pre> -<p>[base/gxicolor.c]</p> -</blockquote> - -<p><strong><a name="2011-01-10T220019.847574Z"></a> -2011-01-10T22:00:19.847574Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Added the source code of the CUPS libraries to the Ghostscript source -package - -Like with zlib, libpng, libjpeg, ... it is now possible to -build the complete Ghostscript (including the CUPS Raster output -device) on systems where there is no CUPS library available. - -Note that currently only the CUPS library source code is added, the -results of the ./configure run in the Makedefs and config.h files, and -the Makefiles are stripped to only build the libraries and nothing -else. The CUPS ./configure command line which was used to obtain -makedefs and config.h was - -./configure --enable-static --without-shared --disable-dbus --without-php \ ---disable-slp --disable-gssapi --disable-ldap --disable-ssl \ ---disable-cdsassl --disable-gnutls --disable-openssl --disable-pam \ ---disable-dnssd --disable-launchd - -This way the built CUPS libraries do not need any system services or -hardware interfaces of Linux. In addition to standard libraries they -use only libz, libpng, libjpeg, and libtiff. These libraries -Ghostscript needs anyway and copies of their source code also ship -with Ghostscript. - -What is still missing is the integration into the build system of -Ghostscript and also the operating-system-independent base/cups.mak -file (like base/png.mak etc.). - -No changes expected in the built Ghostscript as the code is not yet -integrated in the build system. - -</pre> -<p>[cups/libs/cups/backend.c cups/libs/cups/testadmin.c cups/libs/filter/image-pix.c cups/libs/cups/testoptions.c cups/libs/cups/backend.h cups/libs/cups/http-private.h cups/libs/filter/image.c cups/libs/cups/testpwg.c cups/libs/filter/image-sun.c cups/libs/cups/ppd-private.h cups/libs/filter/image.h cups/libs/filter/error.c cups/libs/cups/Dependencies cups/libs/cups/ipp-private.h cups/libs/cups/md5passwd.c cups/libs/cups/notify.c cups/libs/cups/dir.c cups/libs/cups/testarray.c cups/libs/cups/file.c cups/libs/cups/testhttp.c cups/libs/filter/image-png.c cups/libs/filter/image-zoom.c cups/libs/cups/getdevices.c cups/libs/cups/transcode.c cups/libs/cups/dir.h cups/libs/cups/globals.c cups/libs/cups/testppd.c cups/libs/filter/image-tiff.c cups/libs/cups/file.h cups/libs/filter/image-pnm.c cups/libs/cups/transcode.h cups/libs/cups/testipp.c cups/libs/cups/globals.h cups/libs/filter cups/libs/filter/image-photocd.c cups/libs/cups/options.c cups/libs/cups/emit.c cups/libs/cups/localize.c cups/libs/cups/tempfile.c cups/libs cups/libs/cups/testcups.c cups/libs/cups/custom.c cups/libs/cups/pwg-media.c cups/libs/cups/util.c cups/libs/cups/array.c cups/libs/cups/pwg-ppd.c cups/libs/cups/testi18n.c cups/libs/cups/http.c cups/libs/filter/image-jpeg.c cups/libs/filter/Dependencies cups/libs/cups/array.h cups/libs/cups/http-addrlist.c cups/libs/cups/language.c cups/libs/cups/ppd.c cups/libs/cups/http.h cups/libs/cups/md5.c cups/libs/cups/debug.c cups/libs/cups/ipp.c cups/libs/cups/language.h cups/libs/cups/ppd.h cups/libs/cups/backchannel.c cups/libs/cups/http-support.c cups/libs/cups/mark.c cups/libs/cups/md5.h cups/libs/cups/snmp-private.h cups/libs/cups/debug.h cups/libs/cups/Makefile cups/libs/cups/ipp.h cups/libs/cups/dest.c cups/libs/config.h cups/libs/cups/auth.c cups/libs/cups/ipp-support.c cups/libs/filter/common.c cups/libs/cups/langprintf.c cups/libs/filter/image-sgilib.c cups/libs/cups/raster.h cups/libs/filter/common.h cups/libs/cups/attr.c cups/libs/filter/image-private.h cups/libs/cups/sidechannel.c cups/libs/cups/testsnmp.c cups/libs/cups/usersys.c cups/libs/cups cups/libs/cups/cups.h cups/libs/cups/sidechannel.h cups/libs/cups/i18n.h cups/libs/Makedefs cups/libs/cups/testconflicts.c cups/libs/filter/image-colorspace.c cups/libs/cups/adminutil.c cups/libs/cups/http-addr.c cups/libs/filter/interpret.c cups/libs/cups/request.c cups/libs/cups/versioning.h cups/libs/cups/md5-apple.h cups/libs/cups/adminutil.h cups/libs/cups/file-private.h cups/libs/cups/encode.c cups/libs/filter/image-gif.c cups/libs/cups/snprintf.c cups/libs/cups/string.c cups/libs/filter/Makefile cups/libs/cups/getputfile.c cups/libs/filter/image-bmp.c cups/libs/cups/pwg-private.h cups/libs/cups/pwg-file.c cups/libs/cups/string.h cups/libs/filter/raster.c cups/libs/cups/page.c cups/libs/cups/getifaddrs.c cups/libs/cups/snmp.c cups/libs/filter/image-sgi.c cups/libs/cups/testfile.c cups/libs/cups/testlang.c cups/libs/filter/image-sgi.h cups/libs/cups/conflicts.c]</p> -</blockquote> - -<p><strong><a name="2011-01-10T032952.464842Z"></a> -2011-01-10T03:29:52.464842Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Add support for MSVC 10 to msvc32.mak . -</pre> -<p>[psi/msvc32.mak]</p> -</blockquote> - -<p><strong><a name="2011-01-09T021919.656942Z"></a> -2011-01-09T02:19:19.656942Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for color related warnings in bug 691459</pre> -<p>[base/gxi12bit.c base/lib.mak base/gxiscale.c base/gsicc_manage.c base/gxcmap.h base/gxicolor.c base/gscspace.c]</p> -</blockquote> - -<p><strong><a name="2011-01-08T195651.307278Z"></a> -2011-01-08T19:56:51.307278Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Don't discard encoding of a TrueType PDF font when it is not embedded. -Ghyph indexes vary between font versions, and encoding-based mapping -yelds better results in this case. Bug 691693. </pre> -<p>[Resource/Init/pdf_font.ps]</p> -</blockquote> - -<p><strong><a name="2011-01-08T194231.743686Z"></a> -2011-01-08T19:42:31.743686Z regression</strong></p> -<blockquote> -<pre> -Additional changes to support ps2write in the cluster (and nightly and weekly) regression. -</pre> -<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/readlog.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl toolbin/localcluster/compare.pl]</p> -</blockquote> - -<p><strong><a name="2011-01-08T175607.987718Z"></a> -2011-01-08T17:56:07.987718Z regression</strong></p> -<blockquote> -<pre> -Add ps2write testing to the cluster regression. -</pre> -<p>[toolbin/localcluster/build.pl]</p> -</blockquote> - -<p><strong><a name="2011-01-08T175526.179279Z"></a> -2011-01-08T17:55:26.179279Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Fix the code that repairs missing or incorrect /Subtype attribute. Write -a valid attribute (always /Type1) into the font resource. This helps to -avoid confusion caused by an invalid value later on. Bug 691872. -</pre> -<p>[Resource/Init/pdf_font.ps]</p> -</blockquote> - -<p><strong><a name="2011-01-08T105004.294111Z"></a> -2011-01-08T10:50:04.294111Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Fixed typo. -</pre> -<p>[cups/gdevcups.c]</p> -</blockquote> - -<p><strong><a name="2011-01-08T104712.179146Z"></a> -2011-01-08T10:47:12.179146Z Till Kamppeter</strong></p> -<blockquote> -<pre> -CUPS Raster device: Some clean-up. -</pre> -<p>[cups/gdevcups.c]</p> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2011-01-08T103656.827100Z"></a> -2011-01-08T10:36:56.827100Z Till Kamppeter</strong></p> +<p><strong><a name="2011-03-10T145508.103488Z"></a> +2011-03-10T14:55:08.103488Z Ken Sharp</strong></p> <blockquote> <pre> -CUPS Raster: Another approach to fix both bug #691733 and #690435: Set _old values at the beginning of the cups_put_params() function. -</pre> -<p>[cups/gdevcups.c]</p> -</blockquote> +Update the remaining PostScript files (mostly the PDF interpreter) to use the new device +parameters instead of explicitly checking for the device being named 'pdfwrite' or +'ps2write'. -<p><strong><a name="2011-01-07T233317.663910Z"></a> -2011-01-07T23:33:17.663910Z Till Kamppeter</strong></p> -<blockquote> -<pre> -CUPS Raster output device: Use positive values (1) as dummy values to mark that the color depth has changed and therefore memory needs to get rallocated +Some more modification is still required, but we're nearly there. We will continue to +check the device names in gs_pdfwr.ps when setting up the default state for those +specific devices. -WEith this both bug #691733 and bug #690435 get fixed, but this is not -necessarily he right and best solution. +Although not strictly a Distiller device, ps2write declares itself to be 'IsDistiller'. +This is because some PostScript test files were found to behave differently if the +distillerparams operators were available, in particular files would be oriented +differently if the device was deemed to be a Distiller. </pre> -<p>[cups/gdevcups.c]</p> +<p>[Resource/Init/gs_pdfwr.ps Resource/Init/pdf_font.ps Resource/Init/pdf_draw.ps base/gdevpdfb.h Resource/Init/gs_setpd.ps]</p> </blockquote> -<p><strong><a name="2011-01-07T140517.614099Z"></a> -2011-01-07T14:05:17.614099Z Till Kamppeter</strong></p> +<p><strong><a name="2011-03-10T073145.990562Z"></a> +2011-03-10T07:31:45.990562Z Alex Cherepanov</strong></p> <blockquote> <pre> -Fixed search-and-replace error in "cups" output device, bug 691871. +Ignore null object when it is used instead of the gstate dictionary. +Bug 692050. </pre> -<p>[cups/gdevcups.c]</p> -</blockquote> - -<p><strong><a name="2011-01-07T044942.455234Z"></a> -2011-01-07T04:49:42.455234Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that we do not do the ICC optimized flow for color images when our target device does not have standard color mapping procedures. This occurs for example, in the case for the CUPs device where the color mapping procedures map CMYK, RGB and Gray to the current CUPs device color space. For standard gray, RGB and CMYK devices these procedures are avoided as the CMM performs all the required mappings. This commit will show differences in the files for the cups device as well as the psdcmyk device, which also should be using the non-optimized flow due to the use of CMYK + spot colorants, which will not be managed correctly by the CMM in general. The differences int the psdcmyk files that do not have extra spot colorants are tiny. This should fix bug 691760.</pre> -<p>[base/gxi12bit.c base/gdevp14.c base/lib.mak base/gxcmap.c base/gxiscale.c base/gdevnfwd.c base/gxcmap.h base/gxicolor.c]</p> +<p>[Resource/Init/pdf_main.ps]</p> </blockquote> -<p><strong><a name="2011-01-06T191856.657732Z"></a> -2011-01-06T19:18:56.657732Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-10T061917.004672Z"></a> +2011-03-10T06:19:17.004672Z Alex Cherepanov</strong></p> <blockquote> <pre> -Fix a cut-ant-paste error in setting QuantTables for JPXEncode filter. -Bug 691868. +Change all instances of true, false, and null to //true, //false, and //null +to avoid interferance from PS files that redefine them. Bug 692041. </pre> -<p>[base/sdeparam.c]</p> +<p>[Resource/Init/gs_typ32.ps Resource/Init/gs_cidfm.ps Resource/Init/gs_mgl_e.ps Resource/Init/pdf_rbld.ps Resource/Init/gs_resmp.ps Resource/Init/gs_dscp.ps Resource/Init/gs_fonts.ps Resource/Init/gs_wan_e.ps Resource/Init/gs_mex_e.ps Resource/Init/gs_ttf.ps Resource/Init/gs_cspace.ps Resource/Init/gs_cff.ps Resource/Init/gs_dps1.ps Resource/Init/gs_lev2.ps Resource/Init/pdf_sec.ps Resource/Init/gs_l2img.ps Resource/Init/gs_cet.ps Resource/Init/gs_dbt_e.ps Resource/Init/gs_pdf_e.ps Resource/Init/gs_statd.ps Resource/Init/gs_fapi.ps Resource/Init/gs_pdfwr.ps Resource/Init/gs_cidfn.ps Resource/Init/pdf_main.ps Resource/Init/gs_dps.ps Resource/Init/gs_res.ps Resource/Init/gs_ll3.ps Resource/Init/gs_css_e.ps Resource/Init/gs_epsf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_dpnxt.ps Resource/Init/gs_icc.ps Resource/Init/gs_mro_e.ps Resource/Init/pdf_ops.ps Resource/Init/gs_init.ps Resource/Init/pdf_font.ps Resource/Init/gs_ciddc.ps Resource/Init/gs_trap.ps Resource/Init/gs_cidtt.ps Resource/Init/gs_diskn.ps Resource/Init/gs_fntem.ps Resource/Init/pdf_base.ps Resource/Init/gs_sym_e.ps Resource/Init/gs_img.ps Resource/Init/gs_btokn.ps Resource/Init/gs_cidcm.ps]</p> </blockquote> -<p><strong><a name="2011-01-06T110852.017177Z"></a> -2011-01-06T11:08:52.017177Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-10T005808.762234Z"></a> +2011-03-10T00:58:08.762234Z Michael Vrhel</strong></p> <blockquote> <pre> -Minor enhancement to ps2write for DSC output, remove trailing EOF. +Fix for bug 692038. -Prevent ps2write emitting a trailing EOF (0x04) byte when producing DSC-compliant -output. The emission of this byte was leading to warnings about the output containing -binary. +This fixes 3 issues when using a CIELAB based profile for the output device ICC profile. -No differences expected. -</pre> -<p>[base/gdevpdf.c]</p> -</blockquote> +One was a problem when handling separation color spaces when they had the ALL entry and we were going to an additive device. AR does a 1-INK level for the device values and no color management. We were doing the same, but this approach will not work if our destination color space is CIELAB. Now if we are headed toward CIELAB we do the 1-INK to RGB and then transform to CIELAB. -<p><strong><a name="2011-01-05T173542.089947Z"></a> -2011-01-05T17:35:42.089947Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Reverting of commit 11995</pre> -<p>[base/gxipixel.c base/lib.mak]</p> -</blockquote> +Another was that transparency blending should never be done in CIELAB or similar type color spaces. With transparency, the PDF14 device inherits the profile for the target device and if the transparency groups don't specify a color space we would end up blending in CIELAB. The solution was to detect this situation and use the defaultRGB profile for blending. Conversion to CIELAB occurs during the pdf14 put image operation. -<p><strong><a name="2011-01-05T160522.763938Z"></a> -2011-01-05T16:05:22.763938Z Ken Sharp</strong></p> -<blockquote> -<pre> -ps2write DSC enhancement. Alter the default setting of CompressPages and CompressFonts to -true. Gives better conforming output at present (as well as smaller output) -</pre> -<p>[Resource/Init/gs_pdfwr.ps]</p> -</blockquote> +Finally, with shading in transparency, we need to make sure to pass along the transparency device through the shading parameters whenever we have a color mismatch between the pdf14 device and the target device so that the shading will occur in the proper color space. -<p><strong><a name="2011-01-05T154341.972063Z"></a> -2011-01-05T15:43:41.972063Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix three compiler warnings in revision 11997 -</pre> -<p>[base/gdevpdfu.c]</p> +These changes are all related to a non-tested cluster case when we have -sOutputICCProfile=lab.icc</pre> +<p>[base/gdevp14.c base/gxcmap.c base/gstrans.c base/gxclist.h base/gdevtfnx.c base/gsfunc0.c base/devs.mak base/gsicc.c]</p> </blockquote> -<p><strong><a name="2011-01-05T152839.325806Z"></a> -2011-01-05T15:28:39.325806Z Till Kamppeter</strong></p> +<p><strong><a name="2011-03-09T213258.461339Z"></a> +2011-03-09T21:32:58.461339Z Robin Watts</strong></p> <blockquote> <pre> -Use the "x11" output device as default output device for an X-enabled Ghostscript, as "x11alpha" is too buggy - -The simple call "gs <file>" is a common call to check a PostScript -file when debugging printing problems. Unfortunately, this call uses -the "x11alpha" output device which has a lot of bugs, especially on -complex input files. This makes easily a wrong impression of the input -file then. Having a somewhat inferior screen output quality (no -anti-aliasing) is no problem as the mentioned Ghostscript call is only -used for debugging purposes. +Add gxht_thresh.{c,h} to Visual C project. -</pre> -<p>[base/Makefile.in]</p> +CLUSTER_UNCHECKED</pre> +<p>[ghostscript.vcproj]</p> </blockquote> -<p><strong><a name="2011-01-05T141741.770782Z"></a> -2011-01-05T14:17:41.770782Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-09T144440.068733Z"></a> +2011-03-09T14:44:40.068733Z Robin Watts</strong></p> <blockquote> <pre> -ps2write DSC enhancement. Belt and braces approach when emitting a serialised array/proc +Disable PACIFY_VALGRIND in gximono.c. This define is intended to enable +extra code that can be performed so as to ensure that valgrind doesn't +report false positives. As such, disabling it should have no adverse +effects. -This code should break an (already serialised) array or procedure emission if the total -length of the data to write exceeds 255 bytes. The data will be broken at name, array, -string or procedure tokens (ie '/', '[', '(', '<') or a space character. If none of -these occurs in the preceding 255 bytes then we emit a line break anyway and carry on. +Unfortunately, it seems that in the portrait case, if we don't blank the +threshold array before we run, we get diffs. I have therefore taken this +memset out of the PACIFY_VALGRIND case and forced it to always happen. +This probably points to a bug and should be investigated properly. -I do not have any test cases which exercise this code path with a data size > 255 -bytes, so I'm not certain that it works as expected. - -No differences expected as the regression test doesn't exercise ps2write. -</pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> - -<p><strong><a name="2011-01-04T185636.226711Z"></a> -2011-01-04T18:56:36.226711Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Fix spelling errors in a German man page. Thanks to Peter Dyballa for -the patch. Bug 691863. -</pre> -<p>[man/de/gsnd.1]</p> -</blockquote> +No cluster differences expected. -<p><strong><a name="2011-01-04T181941.129921Z"></a> -2011-01-04T18:19:41.129921Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that the presence of source black and white are properly detected with the ICC color management changes. This detection is useful for the optimization of certain ROPs. Previously black and white were detected from looking at the device color. This was a problem since the device black color is usually not pure for a CMYK printer with the ICC changes. This fix updates the detection function so that it looks at the source color and maps it to the default RGB color space where black and white are well defined. </pre> -<p>[base/gxipixel.c base/lib.mak]</p> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2011-01-04T163538.827232Z"></a> -2011-01-04T16:35:38.827232Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-08T200017.821965Z"></a> +2011-03-08T20:00:17.821965Z Robin Watts</strong></p> <blockquote> <pre> -More DSC-compliant ps2write work. +Simple optimisations to non SSE2 versions of halftoning code. There is +probably (certainly!) more performance to come with loop unrolling etc, +but this at least gets us the cheap win of avoiding repeated array accessing, +only setting, not blanking bits etc. -When emitting strings for ps2write, write them as hex strings instead of regular -strings, if the ps2write output is to be DSC-compliant, break the hex strings every -255 bytes or less. Prepend and append newlines to the hex string when emitting -DSC-compliant PostScript to ensure that preceding or following data doesn't cause the -line length to exceed 255 bytes. +Cluster tests show no changes. -No differences expected as ps2write is not currently regression tested. </pre> -<p>[base/gdevpdfu.c]</p> +<p>[base/gxht_thresh.c]</p> </blockquote> -<p><strong><a name="2011-01-04T104832.930138Z"></a> -2011-01-04T10:48:32.930138Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-08T174051.077420Z"></a> +2011-03-08T17:40:51.077420Z Robin Watts</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Write ToUnicode CMap files which Acrobat likes - -Bug #691862 (and also bug #691849) "Unable to copy text from the converted PDF" - -It seems the Adobe documentation lies (or more generously is inconsistent). The -CMap tech note (5014) says that entries are not zero padded, so values less -than 256 are emitted as single bytes, values 256->65535 are two bytes etc. -However the ToUnicode CMap tech note (5411) says: - -"Because a “ToUnicode” mapping file is used to covert from CIDs (which begin at -decimal 0, which is expressed as 0x0000 in hexadecimal notation) to Unicode -code points, the following “codespacerange” definition, without exception, -shall always be used: 1 begincodespacerange <0000> <FFFF>endcodespacerange" +Change to gsroprun1.h to avoid over/underreading the source/texture buffers. -(This is somewhat restrictive, since CIDs can exceed 2 bytes, even though -UTF-16 can't, I could forsee a need to map high CIDs to lower UTF-16 values) +Given a valid byte range we expand that to the smallest enclosing CHUNK range +and guarantee never to access out of that range. Previously we could read +one CHUNK before/after it. -Finally, the PDF Reference (1.7) says: +If this is a problem, simply ensure that CHUNK is byte rather than int on +your platform. This now behaves better than the original code which would +access one byte before/after the defined range. -"The CMap file must contain begincodespacerange and endcodespacerangeoperators -that are consistent with the encoding that the font uses. In particular, for a -simple font, the codespace must be one byte long." - -So the PDF Reference conflicts with the tech note which it references! - -In fact none of the above seems to be quite what Acrobat actually does. - -It seems that Acrobat does not care what size (in bytes) the codespacerange is, -no matter what kind of font is present. However it *does* care what size the -bfrange entries are. For simple fonts the bfrange entries must be single bytes, -for CIDFonts the bfrange entries must be two bytes. Deviation in either case -leads to files which Acrobat cannot process and either causes errors or -incorrect text when copying and pasting. - -Changed the ToUnicode emission (mostly restoring revision 11170 which was removed in -revision 11795 because of bug #691849) so that we emit single byte bfrange and -codespacerange arguments for simple (non-CID) fonts, and emit double byte, padded with -00 arguments to bfrange and codespacerange for CID fonts. - -No differences expected as this only affects text search/copy in Acrobat. -</pre> -<p>[base/gsfcmap.c base/gdevpdte.c]</p> -</blockquote> - -<p><strong><a name="2011-01-03T201958.048424Z"></a> -2011-01-03T20:19:58.048424Z Ray Johnston</strong></p> -<blockquote> -<pre> -Don't bump the 'used' element of the chunk manager structure if the allocation -of a chunk fails. Thanks to Norbert Janssen for noticing this. Bug 691720. -</pre> -<p>[base/gsmchunk.c]</p> -</blockquote> +No cluster differences seen in testing. -<p><strong><a name="2011-01-03T185800.432432Z"></a> -2011-01-03T18:58:00.432432Z Henry Stiles</strong></p> -<blockquote> -<pre> -The optimization in gdevdgbr to detect a device with a "plain" cmyk 1 -bit to rgb mapping was broken because the procedure -cmyk_1bit_map_color_rgb() is obsolete. The hack here is to detect -output formats compatible with gx_get_bits_copy_cmyk_1bit() which is -significantly faster since it does not have to call the device color -decode procedure. The device API should have a member that indicates -the most frequently encountered pixel organizations. </pre> -<p>[base/gdevdgbr.c]</p> +<p>[base/gsroprun1.h]</p> </blockquote> -<p><strong><a name="2011-01-03T162021.454447Z"></a> -2011-01-03T16:20:21.454447Z Henry Stiles</strong></p> +<p><strong><a name="2011-03-08T163516.023687Z"></a> +2011-03-08T16:35:16.023687Z Tor Andersson</strong></p> <blockquote> <pre> -Decode image samples with single precision calculations only. This -area of the code is performance sensitive and there is no need to -convert to and from doubles. Also, "image_set_gray" is now inline but -still not enabled. - -</pre> -<p>[base/gximono.c base/gximage.h]</p> +Add PNG reading support to the bmpcmp tool.</pre> +<p>[toolbin/bmpcmp.c]</p> </blockquote> -<p><strong><a name="2011-01-03T143356.098558Z"></a> -2011-01-03T14:33:56.098558Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-08T151842.397978Z"></a> +2011-03-08T15:18:42.397978Z Ken Sharp</strong></p> <blockquote> <pre> -Fix ps2write : Attach Encoding for symbolic TrueType fonts - -The recent change to not attach Encodings to Sy,bolic TrueType fonts, as per the PDF -spec, meant that ps2write also wrote symbolic TT fonts without a /Encoding. This is not -ideal, because opdfread.ps then attaches a default StandardEncoding to the font. This -simply will not work correctly. - -After some experimentation with extracting (in PostScript) the POST table from the TT -font, sense prevailed. This patch modifies the condition so that if we are producing -output for ps2write we continue to attach a /Encoding. (in this case it doesn't -matter whether we are producing DSC output, we always want the Encoding) +Update to use the new device parameter /PreserveTrMode instead of explicitly checking +for the device name being 'pdfwrite'. No differences expected. </pre> -<p>[base/gdevpdtt.c]</p> +<p>[Resource/Init/pdf_ops.ps]</p> </blockquote> -<p><strong><a name="2011-01-03T062152.574265Z"></a> -2011-01-03T06:21:52.574265Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-08T082754.788378Z"></a> +2011-03-08T08:27:54.788378Z Ken Sharp</strong></p> <blockquote> <pre> -Adjust pdfemptycount variable during .execgroup execution to reflect the -actual stack count. Avoid errors in sc1/scn caused by wrong operand count. -Bug 691624. -</pre> -<p>[Resource/Init/pdf_draw.ps]</p> -</blockquote> - -<p><strong><a name="2011-01-01T161749.255469Z"></a> -2011-01-01T16:17:49.255469Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Change all "/foo /bar load def" into "/foo {bar} bind 0 get def" -in PDF interpreter to ebable operator redefinition with -dDELAYBIND. -Bug 691669, customer 850. -</pre> -<p>[Resource/Init/pdf_draw.ps]</p> -</blockquote> +Activate the new device parameters, and modify the resource code to use the first one +(AllowIncrementalCFF) instead of testing for the pdfwrite device name. -<p><strong><a name="2010-12-31T062359.391706Z"></a> -2010-12-31T06:23:59.391706Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Trap errors that may happen during loading of embedded fonts and try -to load the font by the name. Bug 691045. -</pre> -<p>[Resource/Init/pdf_font.ps]</p> -</blockquote> - -<p><strong><a name="2010-12-30T190959.966731Z"></a> -2010-12-30T19:09:59.966731Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Use -fPIC instead of -KPIC on SunOS for "so" target when compiler is gcc. -Bug 690630, customer 200. +No differences expected. </pre> -<p>[base/configure.ac]</p> +<p>[Resource/Init/gs_cidfn.ps base/gdevpdfp.c]</p> </blockquote> -<p><strong><a name="2010-12-30T141142.974030Z"></a> -2010-12-30T14:11:42.974030Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-08T002607.330315Z"></a> +2011-03-08T00:26:07.330315Z Robin Watts</strong></p> <blockquote> <pre> -Clip excessive size of the radial gradient extensions to the fixed point -range. To avoid trivial differences, try the old fixed point function first -and use new floating point one only when the old function fails. Bug 691775. -</pre> -<p>[base/gspath.h base/gxshade1.c base/gspath.c]</p> -</blockquote> +When using PACIFY_VALGRIND, don't call the memory blanking when the +mallocs have failed. -<p><strong><a name="2010-12-29T130145.722135Z"></a> -2010-12-29T13:01:45.722135Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Ignore transparency group XObject without /Group attribute and issue a -warning about it. Bug 691854. -</pre> -<p>[Resource/Init/pdf_draw.ps]</p> -</blockquote> +This should cure the SEGVs that were introduced, but otherwise cause no +changes. -<p><strong><a name="2010-12-28T031357.856572Z"></a> -2010-12-28T03:13:57.856572Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Implement correct defaults for /FontMatrix attribute in composite CFF -font following analysis by Ken and Masaki (see the comment). Bug 690724. </pre> -<p>[psi/zfont2.c]</p> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-12-27T233439.189121Z"></a> -2010-12-27T23:34:39.189121Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-07T221929.253652Z"></a> +2011-03-07T22:19:29.253652Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix unterminated string used by "%%CreationDate:" comment in ps2write -device. Partial fix for 691853. -</pre> -<p>[base/gdevpdfu.c]</p> +Initialize ht landscape structure to zero when in portrait case. There is a conditional test on the value later.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-12-24T110847.918403Z"></a> -2010-12-24T11:08:47.918403Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-07T215702.879011Z"></a> +2011-03-07T21:57:02.879011Z Robin Watts</strong></p> <blockquote> <pre> -Put a check in place to ensure that the UFST pre version 6 -does not attempt to handle anything other than its own -Microtype fonts. +Correct line endings (were DOS, should be Unix). -This ensures that the UFST 5.x FAPI plugin can coexist -safely with the Freetype FAPI plugin. +No cluster differences. +CLUSTER_UNTESTED </pre> -<p>[psi/fapiufst.c]</p> +<p>[base/gxht_thresh.h base/gxht_thresh.c]</p> </blockquote> -<p><strong><a name="2010-12-24T095039.994493Z"></a> -2010-12-24T09:50:39.994493Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-07T211712.494498Z"></a> +2011-03-07T21:17:12.494498Z Robin Watts</strong></p> <blockquote> <pre> -Where FAPI finds a TTF glyf description to pass into the target font -library, fix the decision on the length of the offset to the glyph -data. Previously, the condition was wrong, and always ended up reading -2 bytes for the offset. +Add new debugging define to gximono.c, PACIFY_VALGRIND. -Bug 691850 - +This enables various small tweaks in the code that stop valgrind throwing +errors. We believe that all the errors thrown are false positives, but +we enable this define anyway until we've sorted the current indeterminisms. +We'll disable it in a few days when we have solved the problems and check that +it really doesn't cause any more. -No cluster differences expected. +Cluster results unknown; probably no change. If this solves indetermisms +then we'll need to understand why. - -</pre> -<p>[psi/zfapi.c]</p> -</blockquote> - -<p><strong><a name="2010-12-24T002830.327488Z"></a> -2010-12-24T00:28:30.327488Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Limit the use of -rdynamic flag to GCC on Linux. This flags is supported -by GCC only if the platform has ELF executable format. Bug 691453. </pre> -<p>[base/configure.ac]</p> -</blockquote> - -<p><strong><a name="2010-12-23T143936.123969Z"></a> -2010-12-23T14:39:36.123969Z Ken Sharp</strong></p> -<blockquote> -<pre> -fix pdfwrite : Always write 2 bytes for ToUnicode CMap ranges - -Bug #691849 "pdfwriter regression: pdf text element is broken" - -revision 11170 modified CMap emission so that bfchar/bfrange entries less than 256 were -emitted as a single byte, as specified in the CMAp specification. However ToUnicode -CMaps don't follow the normal specification (I suspect this is a bug which has been -pickled into the spec by Adobe), and require that values always have 2 bytes. - -reverted 11170 so that we write 2 byte ToUnicode CMap entries. - -No differences expected.</pre> -<p>[base/gsfcmap.c]</p> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-12-23T114120.825457Z"></a> -2010-12-23T11:41:20.825457Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T211156.916525Z"></a> +2011-03-07T21:11:56.916525Z Robin Watts</strong></p> <blockquote> <pre> -ps2write enhancement - -Initialise the SetPageSize flag to true when ProduceDSC is set, so that page sizes are -properly requested by the output PostScript file. +Fix typos, one in a comment, one in an id string. -No differences expected. -</pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> +No cluster differences. -<p><strong><a name="2010-12-22T184813.456231Z"></a> -2010-12-22T18:48:13.456231Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Initial commit of code for creating halftone screens. This code needs additional debugging, especially in the case of edge parameters. It will currently create threshold arrays based upon desired lpi, angle, quantization levels, and device resolution. The method is restricted to angles that are the arctangent of rational numbers. Every attempt is made to achieve the requested lpi by using the rational angle that achieves an lpi over the requested value. Since there is a trade off between lpi and quantization levels, the requested quantization levels are obtained through dithering of the dot cells within the supercell. Essentially, the dots within the supercell do not all take on the same values and can grow at different rates in a visually pleasing manner. There is still a bit of work to do still on this dithering as well as controlling the rate of growth for the dots.</pre> -<p>[toolbin/color/halftone toolbin/color/halftone/halfttoning.sln toolbin/color/halftone/halfttoning/halfttoning.vcproj toolbin/color/halftone/halfttoning toolbin/color/halftone/halfttoning/halftone.c]</p> -</blockquote> +CLUSTER_UNTESTED -<p><strong><a name="2010-12-22T161758.830786Z"></a> -2010-12-22T16:17:58.830786Z Ken Sharp</strong></p> -<blockquote> -<pre> -Just remove a commented out line of code that should have been removed before commit. </pre> -<p>[base/gdevpdfb.c]</p> +<p>[base/gxipixel.c base/gzspotan.c]</p> </blockquote> -<p><strong><a name="2010-12-22T140556.481488Z"></a> -2010-12-22T14:05:56.481488Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T185808.149818Z"></a> +2011-03-07T18:58:08.149818Z Michael Vrhel</strong></p> <blockquote> <pre> -More enhancement work for type 3 fonts with PCL - -Previously we set the horizontal advance argument to the d1 (setcachedevice) operator to -0, and set the Widths entry to 0, for all type 3 bitmap fonts created by rendering the -original font. - -This was required to prevent regression errors with the test suite when we altered the -type 3 font accumulation so that it made more effort to preserve the input character -code, in an attempt to improve searching. - -Revision 11969 fixes a problem with cached characters which was leading to the /Widths -array containing garbage values. With that revision we can now properly set the 'd1' -horizontal advance, and also set the /Widths array correctly. - -No expected differences -</pre> -<p>[base/gdevpdfb.c base/gdevpdti.c]</p> +Fix for improper indexing of reversed portrait image line. We were off by one byte and ended up with one byte not set. Def. a source of indeterminism. Thanks to Robin for tracking this down.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-12-22T135829.830017Z"></a> -2010-12-22T13:58:29.830017Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T154013.201330Z"></a> +2011-03-07T15:40:13.201330Z Ken Sharp</strong></p> <blockquote> <pre> -Fix ps2write/pdfwrite : Up date the show enumerator with the cached character width - -When capturing a character bitmap on the first time it is rendered, pdfwrite and -ps2write get the width of the glyph in the cache device. This is then used to update -values in the show enumerator, and these values are used as the Widths entry for the -glyph. - -When imaging an already cached character, however, the enumerator values are not updated -which can lead to garbage (uninitialised data) being written as values in the /Widths -array. This patch takes the value from the cached character 'wxy' and updates the show -enumerator 'wxy' with it. This is then used as the value for the /Widths array. - -Bug #691836, zweiseit01d4-1.pdf, limitcheck --nostringval-- +Undo revision 12243. The revision makes a debug print dependent on the value of the + 'size_set' variable. Unfortunately, this variable is not defined in the cups_get_matrix +routine. It is defined in the other places it is used (cups_put_params). -No differences expected. -</pre> -<p>[base/gxccache.c]</p> -</blockquote> +This prevents a debug build from compiling on Windows, and I can't see how it would +work on any other OS when built for debug. -<p><strong><a name="2010-12-22T003556.638864Z"></a> -2010-12-22T00:35:56.638864Z regression</strong></p> -<blockquote> -<pre> -Fixed bug with r11967 that redirected output to the wrong directory on the -cluster nodes. +Reverted the change in order to build debug versions of Ghostscript. </pre> -<p>[toolbin/localcluster/run.pl]</p> +<p>[cups/gdevcups.c]</p> </blockquote> -<p><strong><a name="2010-12-21T230747.064606Z"></a> -2010-12-21T23:07:47.064606Z Marcos H. Woehrmann</strong></p> +<p><strong><a name="2011-03-07T142111.345196Z"></a> +2011-03-07T14:21:11.345196Z Ken Sharp</strong></p> <blockquote> <pre> -Attempt to remove obj directories before build and report failure. -This detects the situation where a user manually built on one of -the cluster nodes, leaving an obj directory that can't be overwritten -by the cluster software. -</pre> -<p>[toolbin/localcluster/run.pl]</p> -</blockquote> +Redo revision 12248 in a way which (hopefully!) doesn't cause seg faults. -<p><strong><a name="2010-12-21T230104.915150Z"></a> -2010-12-21T23:01:04.915150Z regression</strong></p> -<blockquote> -<pre> -Merge run.pl and build.pl with nightly regression versions. +Still no differences expected.... </pre> -<p>[toolbin/localcluster/clustermonitor.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p> +<p>[base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]</p> </blockquote> -<p><strong><a name="2010-12-21T175345.618494Z"></a> -2010-12-21T17:53:45.618494Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-07T124047.052280Z"></a> +2011-03-07T12:40:47.052280Z Chris Liddell</strong></p> <blockquote> <pre> -Revise how we set the font types which FAPI should handle, and -ensure that the "dummy" CharStrings dict we set up for Microtype -fonts doesn't get replaced. +Account for fonts in which (some) charstrings have been replaced with +Postscript procedures when FAPI decides an outline, or just a width +is required. The previous code only handled this case for rendered +glyphs from Freetype. -Bug 691810 +Bug 692029 No cluster differences expected. -</pre> -<p>[Resource/Init/gs_fntem.ps Resource/Init/gs_fapi.ps]</p> -</blockquote> - -<p><strong><a name="2010-12-21T104401.003179Z"></a> -2010-12-21T10:44:01.003179Z Chris Liddell</strong></p> -<blockquote> -<pre> -Handle Charstrings being replaced by a procedure. This can happen -even with Microtype fonts (which "pretend" to be Type 1, but don't -actually use CharStrings). - -This commit also includes some UFST 6.x related changes, the complete -UFST 6.x integration should follow in the not too distant future. - -Bug 691834 - -Not cluster differences. </pre> -<p>[psi/fapiufst.c base/gxfapiu.c]</p> -</blockquote> - -<p><strong><a name="2010-12-20T163854.977548Z"></a> -2010-12-20T16:38:54.977548Z Chris Liddell</strong></p> -<blockquote> -<pre> -When we're handling a Type42 font in FAPI, handle the possibility that -the "CharString" we get might be a null object, by falling back to -the notdef glyph. - -Bug 691848 - - -No cluster differences expected. - -</pre> <p>[psi/zfapi.c]</p> </blockquote> -<p><strong><a name="2010-12-18T192714.937495Z"></a> -2010-12-18T19:27:14.937495Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Implement correct bit packing for an indexed image with 4 bit/pixel color -depth in the interface to Luratech JPX library. Bug 691843, customer 532. -</pre> -<p>[base/sjpx_luratech.c]</p> -</blockquote> - -<p><strong><a name="2010-12-18T152443.064303Z"></a> -2010-12-18T15:24:43.064303Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T111219.973357Z"></a> +2011-03-07T11:12:19.973357Z Ken Sharp</strong></p> <blockquote> <pre> -Bug #691835 - -Temporary work-around. It is possible to get into gsicc_init_device_profile with the -graphics state pointer (pgs) being NULL. This happens if ps2write or pdfwrite convert -a masked image into a regular image. - -Because pgs is dereferenced without checking for NULL, this causes a crash. +pdfwrite & ps2write enhancement -Its not immediately clear to me if I need to modify ps2write/pdfwrite so that this -condition doesn't occur, but for now, if pgs is NULL we return from the routine in order -to prevent a crash. +Add some new keys to the device parameters dictionary for these devices. These will be +used to replace the explicit tests against the device name in various places in future +commits. -No differences expected -</pre> -<p>[base/gsicc_manage.c]</p> -</blockquote> - -<p><strong><a name="2010-12-17T165835.097740Z"></a> -2010-12-17T16:58:35.097740Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Install the CJK examples. -</pre> -<p>[base/unixinst.mak]</p> -</blockquote> +These will also later be documented and their use suggested for any devices requiring +the same capabilities. -<p><strong><a name="2010-12-17T165651.880152Z"></a> -2010-12-17T16:56:51.880152Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Mention "ps2pdf14" in the man page for ps2pdf. -</pre> -<p>[man/ps2pdf.1 man/de/ps2pdf.1]</p> -</blockquote> - -<p><strong><a name="2010-12-17T165453.331106Z"></a> -2010-12-17T16:54:53.331106Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Let Ghostscript work with the libjasper provided by the system. -</pre> -<p>[base/sjpx.c]</p> -</blockquote> - -<p><strong><a name="2010-12-17T165049.932561Z"></a> -2010-12-17T16:50:49.932561Z Till Kamppeter</strong></p> -<blockquote> -<pre> -pphs is a script and not a library, put it into the correct group of files in the Makefile. -</pre> -<p>[base/unixinst.mak]</p> -</blockquote> - -<p><strong><a name="2010-12-17T164802.245525Z"></a> -2010-12-17T16:48:02.245525Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Fix stone-old security advisory CVE-2009-4270. -</pre> -<p>[base/gsmisc.c]</p> -</blockquote> - -<p><strong><a name="2010-12-17T164302.736497Z"></a> -2010-12-17T16:43:02.736497Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Build gsx and gsc executables correctly as executables and not as shared libraries. -</pre> -<p>[base/unix-dll.mak]</p> -</blockquote> - -<p><strong><a name="2010-12-17T001641.356524Z"></a> -2010-12-17T00:16:41.356524Z Till Kamppeter</strong></p> -<blockquote> -<pre> -Removed patch noise file. -</pre> -<p>[contrib/pcl3/eprn/eprnrend.c.orig]</p> -</blockquote> - -<p><strong><a name="2010-12-16T170024.131587Z"></a> -2010-12-16T17:00:24.131587Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Don't clamp rectfill to the page. - -Bug #691839 "Invalid EPS conversion with -dEPSCrop" - -Rectangular fills (and only the special case of rectangles) were being clamped to the -width/height of the device when emitted. This can cause problems when a matrix is in -force which reduces the actual co-ordinates, in this case a Pattern with a 0.25 scaling. - -The clamping caused co-ordinates to be reduced, and part of the fill went missing. - -The comment indicated this was to 'work-around' the limit in Acrobat of 32k on user -co-ordinates, but this is too sever a clamp to apply, also the general case path code -does not apply this limit. Altered to make the limit the 32k enforced by Acrobat. - -</pre> -<p>[base/gdevpdfd.c]</p> -</blockquote> - -<p><strong><a name="2010-12-15T161254.275384Z"></a> -2010-12-15T16:12:54.275384Z Ken Sharp</strong></p> -<blockquote> -<pre> -pdfwrite enhancement : Final DSC changes - -Fix a compiler warning, make ProduceDSC=true the default condition so that we create -DSC-compliant PostScript unless told otherwise. - -Update the documentation for pswrite and ps2write in devices.htm and Ps2ps2.htm. Note -that pswrite is now deprecated. - -Modify the pdf2ps and ps2ps scripts to use ps2write instead of pswrite. - -No differences expected. -</pre> -<p>[lib/pdf2ps doc/Ps2ps2.htm lib/pdf2ps.cmd lib/pdf2ps.bat lib/ps2ps doc/Devices.htm base/gdevpdfu.c lib/ps2ps.cmd base/gdevpdfb.h lib/ps2ps.bat]</p> +No differences expected, these are not used yet.</pre> +<p>[base/gdevpdfp.c]</p> </blockquote> -<p><strong><a name="2010-12-15T082258.985898Z"></a> -2010-12-15T08:22:58.985898Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T094302.986503Z"></a> +2011-03-07T09:43:02.986503Z Chris Liddell</strong></p> <blockquote> <pre> -pdfwrite enhancement : more DSC related activity - -Defer the output of the header and the opdfread.ps 'prcoset' until the output file is -closed. This allows us to count the pages and emit the %%Pages: comment in the header -instead of at the end of the file. - -Fix the PageBoundingBox comment to have two % characters instead of one. +Update the second place where we may have to reset the Freetype glyph object. -Check for a new flag 'DSC_OPDFREAD' at the start of opdfread.ps (and write its -definition as part of the header emission in ps2write). If present this prevents the -SetupPageView routine from using setmatrix to reset the CTM to the one saved during -document setup. Because the DSC-compliant output puts save/restore around each page -we don't need to reset the matrix, and the reset prevents the output from working -properly with psnup. If the flag is not present, it is treated as false. +Again, this means we only free the outline or bitmap data, and just let +Freetype "reset" its glyph object between glyphs. -The output now works with GSView, psselect and psnup. The only remaining work is to -track the usage of ProcessDSC and see if we can reuse any of the comments parsed out -of the input. +No cluster differences expected. -No differences expected </pre> -<p>[base/gdevpdfx.h base/gdevpdf.c Resource/Init/opdfread.ps base/gdevpdfu.c]</p> +<p>[psi/fapi_ft.c]</p> </blockquote> -<p><strong><a name="2010-12-13T115736.965203Z"></a> -2010-12-13T11:57:36.965203Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-07T070812.439689Z"></a> +2011-03-07T07:08:12.439689Z Ray Johnston</strong></p> <blockquote> <pre> -pdfwrite enhancement : DSC output - -Add some more comments, and re-arrange a few to make better sense. Initial tests -indicate the output of the code with ProduceDSC does not introduce any new errors. - -Still to do: See if we can re-order the output so that we can write the %%Pages: comment -in the header with the correct number of pages. This requires us to defer writing the -header and ProceSet until the end of the job. - -No differences expected. -</pre> -<p>[base/gdevpdfg.h base/gdevpdf.c base/gdevpdfe.c base/gdevpdfu.c]</p> -</blockquote> +Fix for compositor device chaining in the pdf14 device. This was detected in a +file that did overprint along with transparency. The pdf14 device incremented the +ref_count for the overprint_device, but never decremented it since the 'finalize' +of the pdf14 device was left at NULL rather than being set to the gx_forward_finalize +function which should be used. The gx_device_set_target, rather than rc_assign does +the proper set of the finalize proc pointer so that reference counts for the device +chain are properly maintained. Detected by customer 532 since their device freed +the clist buf_device resulting in the overprint_device having a 'target' pointer +to freed memory, causing a SEGV when the 'finalize' function executed. -<p><strong><a name="2010-12-12T161859.870768Z"></a> -2010-12-12T16:18:59.870768Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Make const_90_degrees an external variable to stop smart optimizers from -converting angle/const_90_degrees to angle*(1/const_90_degrees). Bug 689794. +No regressions expected since in the normal code, the GC frees the devices that +were left unreferenced by the free of the pdf14 device. </pre> -<p>[base/gsmisc.c]</p> -</blockquote> - -<p><strong><a name="2010-12-11T230225.039826Z"></a> -2010-12-11T23:02:25.039826Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Don't break ANSI aliasing rules. Use memcpy() to assign Ghostscript classes -i.e. structures of different type. Fix SEGV on GCC 4.5.1, release build. -Thanks to ubitux@gmail.com for analysis of the problem. Bug 691831. -</pre> -<p>[base/gximag3x.c]</p> -</blockquote> - -<p><strong><a name="2010-12-10T195053.800825Z"></a> -2010-12-10T19:50:53.800825Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Removal of Smask_is_CIE flag in the code as well as removal of code that is no longer used in the soft mask rendering.</pre> -<p>[base/gdevp14.c base/gdevp14.h base/gstrans.c base/gstparam.h base/gxblend.c base/gstrans.h base/gxblend.h]</p> -</blockquote> - -<p><strong><a name="2010-12-10T132611.089772Z"></a> -2010-12-10T13:26:11.089772Z Ken Sharp</strong></p> -<blockquote> -<pre> -pdfwrite enhancement : More work towards DSC compliance - -This is a resubmission of revision 11941, with some additional changes so that it -doesn't crash with pdfwrite on Linux systems. - -We now pass around the 'type' of an object much more when writing. This is so that -we can emit "%%BeginResource/%%EndResource" comment pairs around the resources we write. -It is also required so that we *don't* write these comments around pages. - -The code now emits %%BeginProlog, then writes the opdfread.ps procedure. It then writes -all the various resources used in the document, each with a reasonable DSC comment. Then -it writes %%EndProlog. After this come the page descriptions, each is written with a -%%Page: comment and a %%PageTrailer. Finally we write the %%Trailer, %%Pages -comment (NB we write %%Pages: (atend) in the header comments as we don't know how many -pages there will be until the end) and %%EOF. - -The resources are mostly defined as being of type 'file', as most of them are not normal -PostScript resources. The DSC specification says under the %%BeginResource definition -(file note on p72) "The enclosed segment is a fragment of PostScript language code or -some other item that does not fall within the other resource categories" and so this -seems the best type to use for our purposes. - -The output is now minimally DSC compliant, though there are a few other comments I'd -like to add if possible. Given the way the file is created we are always going to have a -large prolog, and that will need to be copied to all the pages if they are split -individually, in order to make sure that all the required resources are present. - -Technically we could follow the resource chain and write %%IncludeResource comments, -at the page level at least, but this is probably more effort than it is realistically -worth. - -Still need to add some more DSC comment types, and run some extensive testing. - -No differences expected currently. Minimal testing with GSView suggests that the output -so far is DSC-compliant as-is. -</pre> -<p>[base/gdevpdfk.c base/gdevpdfm.c base/gdevpdfx.h base/gdevpdfo.c base/gdevpdf.c base/gdevpdfb.c base/gdevpdtd.c base/gdevpdfc.c base/gdevpdfo.h base/gdevpdfe.c base/gdevpdfu.c base/gdevpdtw.c base/gdevpdfg.c base/gdevpdti.c]</p> -</blockquote> - -<p><strong><a name="2010-12-10T030640.558274Z"></a> -2010-12-10T03:06:40.558274Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Apply proper alpha blending to compute luminosity of mask per the PDF specification. Fixes bug 691822</pre> <p>[base/gdevp14.c]</p> </blockquote> -<p><strong><a name="2010-12-09T165055.001506Z"></a> -2010-12-09T16:50:55.001506Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-06T165219.765042Z"></a> +2011-03-06T16:52:19.765042Z Michael Vrhel</strong></p> <blockquote> <pre> -undo revision 11941 and 11942 as this causes seg faults on Linux. -</pre> -<p>[base/gdevpdfk.c base/gdevpdfm.c base/gdevpdfx.h base/gdevpdfo.c base/gdevpdf.c base/gdevpdfb.c base/gdevpdtd.c base/gdevpdfc.c base/gdevpdfo.h base/gdevpdfe.c base/gdevpdfu.c base/gdevpdtw.c base/gdevpdfg.c base/gdevpdti.c]</p> +Fix to use proper DDA incrementation for interpolation. We still maintain special loops for when there is no scaling or for when it is 2x. This should fix the intdeterminism issues. Tested performance on customer files and no significant difference was observed. About 1500 cluster differences will be reported with this fix.</pre> +<p>[base/lib.mak base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-12-09T153910.142451Z"></a> -2010-12-09T15:39:10.142451Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-06T111548.120325Z"></a> +2011-03-06T11:15:48.120325Z Chris Liddell</strong></p> <blockquote> <pre> -A change to how we get the advance width of the glyph from Freetype. - -Previously, we used the data in the glyph metrics structure, which -are scaled, and the undid the scaling. This is correct method for -everything except the horizontal and vertical advance distances. - -We now get the two advance distances from the glyph structure, -and tell Freetype not to scale them, this avoids the rounding -errors that occur due to Freetype's fixed point number -format. It also saves the (less significant) error when we -previously unscaled the value, and saves a couple of -fairly large double precision calculations. +Instead of destroying and recreating freetype's glyph object for every glyph +we need to render, we can just free the "transient" parts: the bitmap or the +outline. -This does cause a number of changes in the regression suite, -the vast majority are pixel or so differences in glyph -positions. A very few are improvements. +Saves a very small amount of time, and potentially reduces memory pool +fragmentation. -Bugs 691778 and 691777 +No cluster differences expected. </pre> <p>[psi/fapi_ft.c]</p> </blockquote> -<p><strong><a name="2010-12-09T143526.421173Z"></a> -2010-12-09T14:35:26.421173Z Ken Sharp</strong></p> -<blockquote> -<pre> -fix pdfwrite - -Revision 11941 had a typo in gdevpdf.c which spelled %%EndProlog with too many % -characters. -</pre> -<p>[base/gdevpdf.c]</p> -</blockquote> - -<p><strong><a name="2010-12-09T142046.589285Z"></a> -2010-12-09T14:20:46.589285Z Ken Sharp</strong></p> -<blockquote> -<pre> -pdfwrite enhancement : More work towards DSC compliance - -We now pass around the 'type' of an object much more when writing. This is so that -we can emit "%%BeginResource/%%EndResource" comment pairs around the resources we write. -It is also required so that we *don't* write these comments around pages. - -The code now emits %%BeginProlog, then writes the opdfread.ps procedure. It then writes -all the various resources used in the document, each with a reasonable DSC comment. Then -it writes %%EndProlog. After this come the page descriptions, each is written with a -%%Page: comment and a %%PageTrailer. Finally we write the %%Trailer, %%Pages -comment (NB we write %%Pages: (atend) in the header comments as we don't know how many -pages there will be until the end) and %%EOF. - -The resources are mostly defined as being of type 'file', as most of them are not normal -PostScript resources. The DSC specification says under the %%BeginResource definition -(file note on p72) "The enclosed segment is a fragment of PostScript language code or -some other item that does not fall within the other resource categories" and so this -seems the best type to use for our purposes. - -The output is now minimally DSC compliant, though there are a few other comments I'd -lie to add if possible. Given the way the file is created we are always going to have a -large prolog, and that will need to be copied to all the pages if they are split -individually, in order to make sure that all the required resources are present. - -Technically we could follow the resource chain and write %%IncludeResource comments, -at the page level at least, but this is probably more effort than it is realistically -worth. - -Still need to add some more comments, and run some extensive testing. - -No differences expected currently. Minimal testing with GSView suggests that the output -so far is DSC-compliant as-is. - -</pre> -<p>[base/gdevpdfk.c base/gdevpdfm.c base/gdevpdfx.h base/gdevpdfo.c base/gdevpdf.c base/gdevpdfb.c base/gdevpdtd.c base/gdevpdfc.c base/gdevpdfo.h base/gdevpdfe.c base/gdevpdfu.c base/gdevpdtw.c base/gdevpdfg.c base/gdevpdti.c]</p> -</blockquote> - -<p><strong><a name="2010-12-07T141420.090005Z"></a> -2010-12-07T14:14:20.090005Z Ken Sharp</strong></p> -<blockquote> -<pre> -pdfwrite enhancement : more work towards DSC compliant ps2write output - -This should now output pages in the correct order, with %%Page:/%%PageTrailer comments. -Still need to address Resource comments and definitions. - -Committed so that a user can try out the code. No differences expected. -</pre> -<p>[base/gdevpdf.c base/gdevpdfu.c]</p> -</blockquote> - -<p><strong><a name="2010-12-06T203042.463413Z"></a> -2010-12-06T20:30:42.463413Z Michael Vrhel</strong></p> +<p><strong><a name="2011-03-05T174646.608714Z"></a> +2011-03-05T17:46:46.608714Z Till Kamppeter</strong></p> <blockquote> <pre> -Fix for bug 691466. Problem was caused by the DeviceN alternate color space being Lab and the color values not being properly decoded to enable use of the lab ICC profile. A few progressions in the cluster data base with this commit.</pre> -<p>[base/gscdevn.c base/gdevp14.c base/gsicc.c]</p> -</blockquote> +Do not do debug output of an uninitialized variable -<p><strong><a name="2010-12-06T163946.324844Z"></a> -2010-12-06T16:39:46.324844Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Bring JPX Luratech decoder up to the level of Jasper decoder. -1. Don't expand indexed colors when the PDF expects an indexed color space. - Fix rendering of the sample file attached to the bug. -2. Recognize indexed CMYK color space and accept the palettes that are shorter - than 256 colors. Fix comparefiles/Bug689362.pdf -3. Fix memory corruption that happened with 4-bit-per-pixel grayscale image - and pack the nibbles by PS rules. Fix comparefiles/Bug690174.pdf +Thanks to Richard Hughes (hughsient at gmail dot com) for the patch. -Luratech now renders every file in our test suite correctly. We don't have -tests for low values of bits per plane. Bug 691816, customer 532. </pre> -<p>[base/sjpx_luratech.c base/sjpx_luratech.h]</p> -</blockquote> - -<p><strong><a name="2010-12-06T160730.222320Z"></a> -2010-12-06T16:07:30.222320Z regression</strong></p> -<blockquote> -<pre> -Limit clusterpush.pl bmpcmp jobs to 10 megs of changes per file in addition to the 100 changes per file limit. -</pre> -<p>[toolbin/localcluster/checkSize.pl toolbin/localcluster/clustermonitor.pl toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p> -</blockquote> - -<p><strong><a name="2010-12-04T211237.349224Z"></a> -2010-12-04T21:12:37.349224Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for bug 691724. The issue was due to a bug in the code that creates equivalent ICC profiles from CIEABC types. This has a pile of progressions in the cluster data base. I stepped through them with bmpcmp and they appeared to be correct to me. I also altered the DefaultRGB PS color space to by in-sync with the D50 ICC sRGB based default that we are currently using. </pre> -<p>[base/gsicc_create.c Resource/ColorSpace/DefaultRGB]</p> -</blockquote> - -<p><strong><a name="2010-12-04T120200.835522Z"></a> -2010-12-04T12:02:00.835522Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove some extraneous debugging code and variables left in accidentally with the commit -for revision 11932. -</pre> -<p>[base/gxfcopy.c]</p> -</blockquote> - -<p><strong><a name="2010-12-04T115313.468703Z"></a> -2010-12-04T11:53:13.468703Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Hashing /Subrs didn't check all subrs. - -Bug #691815 "ps2pdf fails on attached ps file" - -The new code for hashing /Subrs, to improve font checking performance, stopped comparing -/Subrs between two fonts as soon as either font had an error getting a specific /Subr. - -However it transpires that some fonts can have a null object for a /Subr (used to skip -Subrs that do nothing), and this returns a typecheck error. This led to two fonts which -differed only in the fact that one has (and uses) more Subrs than the other being -perceived as identical. This could lead to pdfwrite using the wrong font when -converting type 1 into CFF fonts and cause errors. - -The code now continues checking remainign /Subrs if a typecheck error occurs, and as an -additional measure also checks the number of /Subrs in each font before deciding if -they are compatible. - -</pre> -<p>[base/gxfont1.h base/gxfcopy.c]</p> -</blockquote> - -<p><strong><a name="2010-12-03T092028.129989Z"></a> -2010-12-03T09:20:28.129989Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Work around Acrobat bug with /Encoding - -Bug #691809 "Regression: some PDF files produced by GhostPCL r11913 cannot be read by -Acrobat 8.2.5" - -Acrobat 4 & 8 have a peculiar bug, if a type 3 font (may affect other font types, but -it seems unlikely) has a WinAnsiEncoding, and no /Differences, then text set in that -font is not displayed by these versions of Acrobat. This may be limited to glyphs -which consist of a bitmap only. - -Forcing the emission of a /Differences array for each glyph used results in these -versions of Acrobat displaying correctly (even though the 'differences' are in fact the -standard Encodings). - -This does seem to be quite definitely an Acrobat bug which we are working around, no -other PDF consumer seems to have a problem with these files. - -</pre> -<p>[base/gdevpdti.c]</p> -</blockquote> - -<p><strong><a name="2010-12-02T181653.794801Z"></a> -2010-12-02T18:16:53.794801Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Remove unused variable.</pre> -<p>[base/gxblend.c]</p> -</blockquote> - -<p><strong><a name="2010-12-02T170945.886919Z"></a> -2010-12-02T17:09:45.886919Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for bug 691803. This provides a fix for cases where we have soft masks embedded within other soft masks. Such rare cases are detected and when they occur and the soft mask type is luminosity, the alpha channel of the soft mask buffer is pre-blended with the luminosity data to give the proper mask values. There appears to a be change in fts_33xx.xps from this commit. However, it appears to me that this file was not being rendered properly, compared to the windows xps viewer, prior to the commit either. I will file a bug related to this issue.</pre> -<p>[base/gdevp14.c base/gdevp14.h base/gxblend.c base/gxblend.h]</p> +<p>[cups/gdevcups.c]</p> </blockquote> -<p><strong><a name="2010-12-02T095828.497029Z"></a> -2010-12-02T09:58:28.497029Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-04T192750.114304Z"></a> +2011-03-04T19:27:50.114304Z Till Kamppeter</strong></p> <blockquote> <pre> -minor bug, warning message point to incorrect source directory. - -Bug #691811 "incorrect error message" - -Simply alter the source path in a warning. - -No differences expected. +Correction on Richard Hughes' patch for color management in the CUPS filters. </pre> -<p>[psi/imain.c]</p> -</blockquote> - -<p><strong><a name="2010-12-01T164120.443841Z"></a> -2010-12-01T16:41:20.443841Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Additional debug code to help in soft mask problems.</pre> -<p>[base/gdevp14.c]</p> +<p>[cups/colord.c]</p> </blockquote> -<p><strong><a name="2010-12-01T051655.267986Z"></a> -2010-12-01T05:16:55.267986Z Michael Vrhel</strong></p> +<p><strong><a name="2011-03-04T175100.067911Z"></a> +2011-03-04T17:51:00.067911Z Henry Stiles</strong></p> <blockquote> <pre> -Fix so that the blend compositor actions are only removed from the clist compositor queue if they are completely over-ridden by a subsequent compositor action. Previously no check was made to see that the same settings were being up-dated by the new action. +Fix a warning and type error. Code should produce the same results, +so no testing. -This fixes two P1 customer bugs and has several progressions in the test suite but one file Bug691783.pdf has both regressions and progressions. I will get the page 18 regressions into a bug.</pre> -<p>[base/gdevp14.c base/gxclimag.c base/gxcldev.h]</p> -</blockquote> +CLUSTER_UNTESTED -<p><strong><a name="2010-11-29T211232.441057Z"></a> -2010-11-29T21:12:32.441057Z regression</strong></p> -<blockquote> -<pre> -Additonal improvement in the cluster's ability to be able to recover from machines going down late in the run. Machines are put into a standby state when there are no jobs left to send and they have processed all of their jobs until all machines are in the standby state, then all the machines are released from standby and can upload their logs </pre> -<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/run.pl]</p> -</blockquote> - -<p><strong><a name="2010-11-29T185503.883221Z"></a> -2010-11-29T18:55:03.883221Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for issues with the default ICC directory. The PS interpreter now checks if the default name is OK before setting to LIBPATH/iccprofiles . Also, the current name is first tested before we prepend with the directory name, to avoid doing double applications of the profile directory. Thanks to Ray for the fixes in gs_lev2.ps</pre> -<p>[base/gsicc_manage.c Resource/Init/gs_lev2.ps]</p> -</blockquote> - -<p><strong><a name="2010-11-29T183038.060525Z"></a> -2010-11-29T18:30:38.060525Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for bug 691748. The idle optimizations for the softmask are not really valid since we have since created the proper bounding box for the soft mask in a previous commit. In the cluster push testing, some files came back as having problems with the psdcmyk device. Checking, it appears that these issues are not related to this fix but are another bug. I am working on this now and will submit a bug.</pre> -<p>[base/gdevp14.c]</p> +<p>[base/gdevdgbr.c]</p> </blockquote> -<p><strong><a name="2010-11-29T144517.958276Z"></a> -2010-11-29T14:45:17.958276Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-04T133411.568425Z"></a> +2011-03-04T13:34:11.568425Z Robin Watts</strong></p> <blockquote> <pre> -Due to "lazy evaluation" of softmask groups, the graphics state can change between -the creation of the softmask group form, and when it is executed. - -We'll now save the gstate and (most of) the ExtGState when the softmask group is -defined, and then set both before evaluting the object. A few ExtGState entries -are not easily set directly, so those are missing. - -This partially fixes Bug 691157, and fixes Bugs 690351, 691348 and 690535. It -also resolves the remaining issue with 690535. - -Cluster differences as follows: -Bug690535.pdf (noted above) -Bug690022.pdf, Bug690115.pdf, Bug690208.pdf, fts_26_2601.pdf and -fts_26_2603.pdf are all improved when compared to Acrobat. - -A few xps->pdf conversions thru pdfwrite render differently, but they were -wrong before, and slightly differently wrong now. I believe the PDFs are -"incorrect". +Add FIXME to gximono.c about possible future optimisation, so it is not +forgotten. +CLUSTER_UNTESTED </pre> -<p>[Resource/Init/pdf_draw.ps]</p> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-11-29T143525.792013Z"></a> -2010-11-29T14:35:25.792013Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-04T093504.845642Z"></a> +2011-03-04T09:35:04.845642Z Chris Liddell</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Type 3 font capture and charpath operations - -Bug #691033 "Regression: 14-01.PS fails with pdfwrite" - -The first time a type 3 glyphis encountered we start a charproc accumulatiopn and -exit to run the BuildChar/BuildGlyph. On return to the text processing, if the -operation was a charpath, this would take precedence over closing the accumulator which -would lead to significant later problems. - -Modified the code path to allow for the charproc accumulation to finish and if this is -a charpath operation to rerun the operation using the newly captured glyph program. - -Note this can only occur if the first operation on a given glyph in a type 3 font is -for a charpath. - +Only attempt to create files in the "cups" directory if it exists. </pre> -<p>[base/gdevpdtt.c]</p> +<p>[base/configure.ac]</p> </blockquote> -<p><strong><a name="2010-11-27T182343.131547Z"></a> -2010-11-27T18:23:43.131547Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-04T064529.360251Z"></a> +2011-03-04T06:45:29.360251Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix (pdfwrite) : pointers not marked for garbage collection - -Bug #691779 "SegFault with pdfwrite and more than one cid font" - -pdfwrite does lazy creation of Identity ToUnicode CMaps for inclusion in output PDF -files (2 CMaps, one for horizontal and one for vertical writing). These pointers were -not marked for the garabge collector, but were stored directly in the pdf device -structure. - -The CMaps were assigned to a pdfont resource type, where the pointer to the CMap *was* -marked for the garbage collector. This meant that if the pdfont resource was moved as -a result of garbage collection, the CMap could be moved as well. This left a dangling -pointer in the device structure. - -If another font resource required an identity CMap then the now garbage pointer from -the device structure would be assigned. If the new font resource was moved as a result -of garbage collection, then the attempt to relocate the CMap would fail and cause a -crash. - -Fixed by marking the pointers in the device structure for the garbage collector. - -No differences expected. -</pre> -<p>[base/gdevpdfx.h]</p> +Reorganization of threshold code to move all the thresh holding operations into a new file. </pre> +<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gximage.h base/gxht_thresh.c base/gsiparam.h]</p> </blockquote> -<p><strong><a name="2010-11-26T105951.673656Z"></a> -2010-11-26T10:59:51.673656Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-04T061653.560659Z"></a> +2011-03-04T06:16:53.560659Z Alex Cherepanov</strong></p> <blockquote> <pre> -Update the FAPI/UFST interface to correctly scale the points when retrieving an outline. -Since FAPI now expects points in 32.32 fixed point form. +Add missing test for /packedarraytype during recursive dereferencing +of composite PDF objects. Bug 692018, customer 850. </pre> -<p>[psi/fapiufst.c]</p> +<p>[Resource/Init/pdf_base.ps]</p> </blockquote> -<p><strong><a name="2010-11-25T210322.187304Z"></a> -2010-11-25T21:03:22.187304Z Robin Watts</strong></p> +<p><strong><a name="2011-03-03T222022.363870Z"></a> +2011-03-03T22:20:22.363870Z Henry Stiles</strong></p> <blockquote> <pre> -Fix for bug 691785. - -The bitmap mask clip device has a long standing bug when attempting to clip -a bitmap through a 1bpp bitmap (gxclipm.c, clip_runs_enumerate, line 283ish). - -The code detects runs of 'on' pixels in the mask. It then keeps the last run -it found in a 1 place buffer (called 'previous'). This therefore represents -the previous run found. Whenever we find a new run, we check to see if we can -add it to the previous run to try to form a larger (vertical) rectangle. If -we can't, we should write the previous rectangle out and remember the current -one. - -Unfortunately the code was writing the current rectangle out, rather than the -previous one. This has the effect of losing the first run on most lines out. - -130 differences shown in cluster testing; confirmed in bmpcmp as -progressions. +The get_bits() device call was assumed to return copied data and fill +in the allocated memory pointed to by the variable row, in fact the +gets_bit call can also just return a pointer and row is never +initialized, now we detect that. This broke raster operations for the +display device and appears to have resulted in the use of +uninitialized data in other files. A sampling of changed files showed +single pixel differences in files. </pre> -<p>[base/gxclipm.c]</p> +<p>[base/gdevdgbr.c]</p> </blockquote> -<p><strong><a name="2010-11-25T091213.562173Z"></a> -2010-11-25T09:12:13.562173Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-03T202923.683592Z"></a> +2011-03-03T20:29:23.683592Z Robin Watts</strong></p> <blockquote> <pre> -Remove a now-unused variable to silence a compiler warning. +Update plibc and plibk to output pams when built with DEBUG_DUMP. -No differences expected.</pre> -<p>[base/gdevpdfb.c]</p> -</blockquote> +No cluster differences possible as this code is not used in cluster testing. -<p><strong><a name="2010-11-24T221834.999818Z"></a> -2010-11-24T22:18:34.999818Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Style clean up of gdevp14.c for white space, comments, long lines and dead code.</pre> -<p>[base/gdevp14.c]</p> -</blockquote> - -<p><strong><a name="2010-11-24T174439.808162Z"></a> -2010-11-24T17:44:39.808162Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that we handle the \B command properly when we have transparency. The stroke should be drawn in a knock-out fashion rather than blended with the fill. This was achieved by adding in the push of a knockout transparency group for the stroke operation. The opacity for that group had to be 1 rather than what ever the current graphic state was (otherwise you end up with the opacity applied twice). That change revealed an issue in the clist when a transparency group is pushed where the opacity for the pdf14 clist device was being altered without having the information passed into the clist. Fixing that required a few changes to make sure that the blend parameter changes for the transparency group end up written in the same bands as the group push rather than all bands like the normal blend parameter change compositor action does. A few changes were needed in the clist compositor writing code to make sure that this special blend parameter change did not push a new cropping item on the cropping stack. This commit results in a lot of progressions. However, the cluster push revealed a couple files fts_06_0608.pdf.pdf.ppmraw for example, which may have an issue. These are being checked and if found to be an issue a new bug report will be filed.</pre> -<p>[Resource/Init/pdf_ops.ps base/gdevp14.c base/gxclimag.c base/gxblend.c base/gstrans.h base/gxblend.h]</p> +CLUSTER_UNTESTED</pre> +<p>[base/gdevplib.c]</p> </blockquote> -<p><strong><a name="2010-11-24T162125.266704Z"></a> -2010-11-24T16:21:25.266704Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-03T202343.920044Z"></a> +2011-03-03T20:23:43.920044Z Robin Watts</strong></p> <blockquote> <pre> -pdfwrite enhancement : attempt to make PCL bitmap fonts into searchable type 3 - -In general pdfwrite only resorts to making a bitmap from a font when it cannot handle -the original font type, which is rare for PostScript, PDF and XPS. However all PCL -bitmap fonts are handled this way. - -When this happens, the bitmap is stored into a general type 3 font, a 'bucket' where all -such glyphs are stored. When this font is full, a new one is started and so on. The text -stored in the PDF page stream references the correct type 3 font, but usually the -character code will be unrelated to the original character code. - -For PCL bitmap fonts pdfwrite actually starts by creating a type 3 font to hold the -PCL bitmaps, but doesn't use it. This patch tries to store the bitmaps in the type -3 font where possible, using the character code from the original PCL document. -Although this will not create searchable text in the general case, it does seem that -there are a good number of PCL documents which do use an ASCII encoding and so will -produce a searchable PDF file. - -There are several caveats: +Add new pamcmyk4 device. Identical to pamcmyk32 device, but works in 1 bit +per component, rather than 8. -1) This only works at all with cached glyphs. Glyphs which are too big to fit in the -cache are instead rendered as images, not text at all. The cache has a compiled limit -of 2500 for the height of the bitmap, but this needs to take the resolution which is -being used for rendering into account. The default resolution for pdfwrite is 720 dpi -which means that bitmaps larger than ~125 rows will not be cached. (see below for more) - -2) Certain kinds of text operations can't be handled at all; any case where a character -code does, or may, exceed 256 cannot be handled. These cases are handled as before by -placing in a special font with a unique character code and called from there. - -3) If the font matrix is not the identity we cannot handle the glyphs, as the bitmaps -stored in the cache already include any transformations present in the Fontmatrix and -we can't undo those transformations to the bitmap. In practice this means that if the -canvas orientation (not the media) is not portrait, then this will cause the text to -be non-searchable. - -4) The Acrobat searching algorithm does not work very well with this kind of text. In -our case each glyph is individually positioned on the page rather than being written -as a continuous stream of characters. Acrobat seems unable to find more than about -three glyphs in succession this way. - - -There is no further scope for improvement in pdfwrite as far as I can see. The only -way to handle this better would be to make changes in the PCL interpreter so that the -bitmap PCL font is created as an actual font (probably a TrueType). This would mean that -the text would be stored in the PDF file as real text, the FontMatrix would not be a -problem, caching would not be an issue. This is probably a large project, but I suspect -less of a pain than this enhancement was. - -Caching -======== -In gsfont.c is a #define: -#define blimit_LARGE 2500 /* blimit/upper - max size of a single cached char */ - -Increasing this will allow larger glyphe to be cached. There is another limit in -gxchar.c: -static const uint MAX_TEMP_BITMAP_BITS = 80000; - -This should not be altered. Care should be exercised if increasing the maximum size -of cached characters as these are emitted in the PDF file as inline images in a type -3 font. The PDF spec recommends that inline images should not exceed 4Kb and some -consumers may not be able to cope with images which exceed this limit. - -</pre> -<p>[base/gdevpdfb.c base/gdevpdti.c]</p> +No cluster differences expected as this code isn't tested.</pre> +<p>[psi/msvc.mak base/unix-gcc.mak base/gdevpbm.c base/devs.mak]</p> </blockquote> -<p><strong><a name="2010-11-23T160144.675647Z"></a> -2010-11-23T16:01:44.675647Z Ray Johnston</strong></p> +<p><strong><a name="2011-03-03T175148.590954Z"></a> +2011-03-03T17:51:48.590954Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix chunk_free_all_remaining typo so that mulitple object chunk list gets -traversed and freed first, then the single object chunk list. Thanks to -Norbert Janssen for spotting this. Bug 691791. -</pre> -<p>[base/gsmchunk.c]</p> +Enabling of thresholding code as default image rendering of monochrome/indexed images for monochrome devices. This will result in about 2432 differences reported. I stepped through them in a bmpcmp to check for serious issues. The minor halftone differences were due to the fact that we step in the device space for pixel replication in the threshold code but step in source space for the rect fill code. Enabling this code now will make it easier to track issues as we expand the use of the thresholding code.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-11-23T153628.976110Z"></a> -2010-11-23T15:36:28.976110Z Robin Watts</strong></p> +<p><strong><a name="2011-03-03T154846.192376Z"></a> +2011-03-03T15:48:46.192376Z Robin Watts</strong></p> <blockquote> <pre> -Fix for Bug 691783. A tiny tweak to that submitted by Sebastian Rasmussen. -Many thanks! - -When closing down render threads we check to see if the underlying -allocator had to be wrapped to make it thread safe. If it was, we free the -wrapped version too. Unfortunately the test to see "did we have to wrap it" -was accessing memory we'd just freed. +Add plib device (c and h) files to ghostscript project file. -The fix is to move the code that finds the underlying allocator to before -we free the memory. +No cluster differences expected as project file is not used by cluster. -Cluster testing shows no differences. - -</pre> -<p>[base/gxclthrd.c]</p> +CLUSTER_UNTESTED</pre> +<p>[ghostscript.vcproj]</p> </blockquote> -<p><strong><a name="2010-11-23T123356.433376Z"></a> -2010-11-23T12:33:56.433376Z Robin Watts</strong></p> +<p><strong><a name="2011-03-03T000827.251299Z"></a> +2011-03-03T00:08:27.251299Z Marcos H. Woehrmann</strong></p> <blockquote> <pre> -In an effort to understand the shading code I put together a 'map' of the -function calls as comments. This has been hanging around my harddisc for ages -and I'm now committing it to avoid it being lost. +Added the ability to specify bmpcmp in addition to a normal clusterpush.pl +operation. Both commands will be queued in the correct order. -Comment change only - no cluster changes expected. +Examples: -</pre> -<p>[base/gxshade1.c]</p> -</blockquote> + ./clusterpush.pl gs bmpcmp + ./clusterpush.pl bmpcmp gs pcl xps ls -<p><strong><a name="2010-11-23T084610.878077Z"></a> -2010-11-23T08:46:10.878077Z Ken Sharp</strong></p> -<blockquote> -<pre> -Revert revision 11901. +Note that the order of the options is not signficant. -Because of the way that PCL draws bitmap fonts directly to the cache there is no -possibility of making uncached glyphs work properly. Also the code for cached glyphs is -much too forgiving and attempts to add glyphs which cannot be handled. Finally there is -no provision for type 3 fonts with non-identity matrices. Because the bitmaps in the -cache already have the scaling/rotation/shearing and clipping applied, we cannot have -a type 3 font with a non-identity matrix. +The command line parser for clusterpush.pl changed signficantly with this +revision. It should be backwards compatible with the previous version +but it's possible that subtle differences exist. If a clusterpush.pl +command line behaves differently than you expect please open a bug. -The code will be revised and recommitted. -</pre> -<p>[base/gdevpdti.h base/gdevpdfx.h base/gdevpdfb.c base/gdevpdt.h base/gdevpdti.c base/gdevpdfi.c]</p> -</blockquote> - -<p><strong><a name="2010-11-20T225509.754787Z"></a> -2010-11-20T22:55:09.754787Z regression</strong></p> -<blockquote> -<pre> -Improved the cluster code's ability to be able to recover from machines going down late in the run. </pre> -<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/run.pl]</p> +<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/clusterpush.txt]</p> </blockquote> -<p><strong><a name="2010-11-18T192131.928351Z"></a> -2010-11-18T19:21:31.928351Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-02T221239.208205Z"></a> +2011-03-02T22:12:39.208205Z Robin Watts</strong></p> <blockquote> <pre> -Ensure we set SHARE_FT correctly when we end up using the system installed -freetype library. +Fix rop operation on plib device. Previously, I'd disabled get_bits_rectangle +on the buffer device as the data is normally in the format we need it in +anyway, so it's a NOP. Unfortunately it's needed for rop operation, so +reintroduce it. -Bug 691776. +To avoid infinite loops, we have to cope with GB_RETURN_POINTER. This is +easy to add to the gdevmpla.c device, but it's less clear that adding it +into the mem device is the right thing to do. We therefore introduce a +shim function to cope with GB_RETURN_POINTER with the mem device. -No cluster differences expected. +No cluster differences expected as this is disabled by default. -</pre> -<p>[base/configure.ac]</p> +Testing shows that the planar device is now very close to the non planar +equivalent.</pre> +<p>[base/gdevplib.c base/gdevmpla.c]</p> </blockquote> -<p><strong><a name="2010-11-18T005220.670104Z"></a> -2010-11-18T00:52:20.670104Z regression</strong></p> +<p><strong><a name="2011-03-02T205046.635530Z"></a> +2011-03-02T20:50:46.635530Z regression</strong></p> <blockquote> <pre> -Two changes to the local cluster system: +Minor bug fixes and improvements to the cluster system, the most +signifcant of which is the addition of "CLUSTER_UNTESTED" detection. +If this keyword appears anywhere within the log message of a commit that +revision will not be tested by the cluster. -1. A warnings check is now performed on the code under test (both commit -and user tests). +Less interesting changes include: -2. In order to better recover from nodes going offline near the end -of a cluster run nodes are paused after all their jobs have been sent. -This way the jobs from an unresponsive node that isn't detected until -all jobs have been distributed can be reassigned. + Fix for bmpcmp if large numbers of differences are produced -Also some minor cleanup (dividing the clustermaster log into .log and -.dbg files, supressing some uneeded debugging messages, etc.) + Addition of 'svn cleanup' calls before 'svn update' to handle nodes that + crashed during previous 'svn update' and left the repositories locked -</pre> -<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/readlog.pl toolbin/localcluster/pngs2html.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl toolbin/localcluster/cachearchive.pl toolbin/localcluster/compare.pl]</p> -</blockquote> + Set status of all nodes to idle after jobs are completed. -<p><strong><a name="2010-11-16T224926.969992Z"></a> -2010-11-16T22:49:26.969992Z Ray Johnston</strong></p> -<blockquote> -<pre> -Fix for PCL that uses the chunk allocator (which is not inherently thread safe) -when NumRenderingThreads > 1. Adds 'is_thread_safe' to the gs_memory_status so -that clist_setup_render_threads can wrap an unsafe allocator in a locking wrapper. + Fix bugs that caused bmpcmp completed emails to be appended to the + previous message. -Also restore the optimizations to the chunk memory allocator to keep two lists -(one for multiple object chunks and another for single object chunks) and fixes -the chunk_free_object so that the correct list is chosen. Even if not found on -the selected list, the other list will be scanned and a diagnostic printed if -the wrong chunk list was selected (belt and suspenders). My testing with the -lj*.prn files did not show this problem. </pre> -<p>[base/lib.mak base/gsmemlok.c base/gsmchunk.c base/gxclthrd.c base/gsmalloc.c base/gsmemret.c base/gsalloc.c base/gsmemory.h base/gsmemraw.h]</p> -</blockquote> - -<p><strong><a name="2010-11-16T144831.620067Z"></a> -2010-11-16T14:48:31.620067Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that the initial gray color spaces in the graphic state are properly color managed. Previously, if we immediately started drawing in the document with a gray color space, the initial un-managed color space in the graphic state was used and this was not associated with the specified gray source profile. With this fix we initialize the stroking and filling color spaces to be ICC color spaces associated with the profile for default_gray in the icc manager. Also a fix for an issue in littleCMS. When merging profiles, littleCMS will often do an optimization where it approximates 1-D LUTs with an exponent operation for use during merging and interpolation of the profile structures. If the curve is very steep, as in like a step function, it should not do this approximation. This was an issue when we had profiles that provided thresholding operations with their 1-D LUTs. I spoke with Marti about this issue a couple weeks ago. This commit will create over 6000 differences in the regression test. I reviewed many of these and they all are minor differences in gray colors as expected. These are differences where we were drawing unmanaged colors.</pre> -<p>[base/gsicc_manage.c psi/zusparam.c base/gsicc_manage.h lcms/src/cmsgmt.c]</p> +<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/pngs2html.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p> </blockquote> -<p><strong><a name="2010-11-16T143357.040738Z"></a> -2010-11-16T14:33:57.040738Z Ken Sharp</strong></p> +<p><strong><a name="2011-03-02T185123.645025Z"></a> +2011-03-02T18:51:23.645025Z Michael Vrhel</strong></p> <blockquote> <pre> -pdfwrite enhancement : attempt to make PCL bitmap fonts into searchable type 3 - -In general pdfwrite only resorts to making a bitmap from a font when it cannot handle -the original font type, which is rare for PostScript, PDF and XPS. However all PCL -bitmap fonts are handled this way. - -When this happens, the bitmap is stored into a general type 3 font, a 'bucket' where all -such glyphs are stored. When this font is full, a new one is started and so on. The text -stored in the PDF page stream references the correct type 3 font, but usually the -character code will be unrelated to the original character code. - -For PCL bitmap fonts pdfwrite actually starts by creating a type 3 font to hold the -PCL bitmaps, but doesn't use it. This patch tries to store the bitmaps in the type -3 font where possible, using the character code from the original PCL document. -Although this will not create searchable text in the general case, it does seem that -there are a good number of PCL documents which do use an ASCII encoding and so will -produce a searchable PDF file. - -There are 3 parts to this enhancement: - -1) Cached glyphs. When the current font is a type 3 font, and the text operation is -one which might result in an ASCII character code, and we can manufacture a glyph name -for the resulting character code, store the glyph in the type 3 font (rather than the -general 'bucket' font), using the character code and glyph name. Glyphs which can't -be handled this way for any reason are still stored in the general recipient 'bucket' -font. - -2) Uncached glyphs. Glyphs which are too large for the cache are rendered as images. The -image handling code has been extensively reworked to try and detect this situation and, -if the criteria for cached glyphs above also holds true, to store the image as a glyph -in a type 3 font and draw text in the PDF content stream instead of an image. Images -which do not fulfil these criteria are still handled as images. - -3) Recached glyphs. If the glyph cache fills up, glyphs will be flushed to make space. -If a glyph is then reused we go through the caching case again (for large glyphs which -are uncached we end up repeating the code every time the glyph is used). We now attempt -to spot this by determining that the glyph in the font has already been used, and rather -than storing a new copy of the glyph, as the old code did, we simply emit text into -the page content stream. - -Note that there is a recommendation that inline images in PDF should not exceed 4KB. -Since CharProcs must use inline images, bitmaps which exceed this size will be rendered -as images, not text (they will also exceed the cache size and so are always rendered -uncached). - -</pre> -<p>[base/gdevpdti.h base/gdevpdfx.h base/gdevpdfb.c base/gdevpdt.h base/gdevpdti.c base/gdevpdfi.c]</p> +Introduction of a member variable in gs_image1_t, which will let us know the original source type of the image. For example if, the parent source were type3 this spawns two type1 images. One for the mask and one for the image data. The mask is rendered using image render simple. If the image is monochrome or indexed, it is rendered with the renderer in gximono.c . If we are going to a halftone monochrome device, we end up using the fast threshold based renderer which has its interpolation stepping in device space as opposed to source space. This causes very minor differences between the mask and the image data. To avoid this, we use the old rect_fill code for the image type3 data to ensure a more exact spatial match.</pre> +<p>[base/gximono.c base/gximage1.c base/gximage2.c base/gximage3.c base/gximage4.c base/gximage.h base/gximag3x.c base/gsiparam.h]</p> </blockquote> -<p><strong><a name="2010-11-16T135836.196330Z"></a> -2010-11-16T13:58:36.196330Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-03-02T133952.433442Z"></a> +2011-03-02T13:39:52.433442Z Robin Watts</strong></p> <blockquote> <pre> -Prefer character codes < 256 during construction of /CharStrings and -/Encoding attributes of a symbolic Type 42 font. Bug 691753. -</pre> -<p>[Resource/Init/gs_ttf.ps]</p> -</blockquote> +Fix bmpcmp bug; the map array was being incorrectly sized, resulting in +occasional memory corruption. -<p><strong><a name="2010-11-15T183050.012584Z"></a> -2010-11-15T18:30:50.012584Z Henry Stiles</strong></p> -<blockquote> -<pre> -reverts 11877 which needs a bit more work</pre> -<p>[base/gsmchunk.c]</p> +No cluster differences expected.</pre> +<p>[toolbin/bmpcmp.c]</p> </blockquote> -<p><strong><a name="2010-11-15T091150.168011Z"></a> -2010-11-15T09:11:50.168011Z Chris Liddell</strong></p> +<p><strong><a name="2011-03-02T000925.760114Z"></a> +2011-03-02T00:09:25.760114Z Robin Watts</strong></p> <blockquote> <pre> -Fix a memory leak when interpolating image data. We were allocating a colour -management buffer for every interpolated scan line from the currently -buffered image data, but only releasing the last one. - -We'll now allocate the buffer (and initialise the buffer desc structure) -only once, and free the buffer once when we're done. - -No cluster differences expected. - -Bug 691772 +Debug output for gdevplibm (monochrome planar interlaced bands) was broken +and writing malformed pbms. Simple fix - move the mono output code to the +mono branch of the if rather than the grey one. -(NOTE: the test file for this still appears to go into an infinite loop -during interpolation). - -</pre> -<p>[base/gxiscale.c]</p> -</blockquote> - -<p><strong><a name="2010-11-14T211615.954493Z"></a> -2010-11-14T21:16:15.954493Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Make a macro for the default ICC profile name and set it in the proper locations.</pre> -<p>[base/gsicc_manage.c psi/zusparam.c base/gsicc_manage.h]</p> +No cluster differences expected.</pre> +<p>[base/gdevplib.c]</p> </blockquote> -<p><strong><a name="2010-11-06T153618.568592Z"></a> -2010-11-06T15:36:18.568592Z Michael Vrhel</strong></p> +<p><strong><a name="2011-03-01T193056.622647Z"></a> +2011-03-01T19:30:56.622647Z Robin Watts</strong></p> <blockquote> <pre> -Fix for a string handling bug that occurred when the device ICC profile name was smaller than the default device profile name. Also, additional code to ensure that the ICC path and the device profile name are properly combined when needed. Finally, if the device profile name is given as an absolute name the icc directory is not added to it.</pre> -<p>[base/lib.mak base/gsdparam.c base/gsicc_manage.c]</p> +Remove DOS line endings from .gitignore files.</pre> +<p>[.gitignore /trunk/ghostpdl/.gitignore]</p> </blockquote> -<p><strong><a name="2010-11-05T221205.617541Z"></a> -2010-11-05T22:12:05.617541Z Michael Vrhel</strong></p> +<p><strong><a name="2011-03-01T171830.158752Z"></a> +2011-03-01T17:18:30.158752Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix so that when compositing with tags, the tos tag data has no effect on the nos tag data if the pixel alpha value is 0. Fixes Bug 691752.</pre> -<p>[base/gxblend1.c]</p> +Fix for error introduced in non-SSE2 code when I removed the inclusion of the transfer function into the threshold values.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-11-05T155335.817121Z"></a> -2010-11-05T15:53:35.817121Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-28T223128.419926Z"></a> +2011-02-28T22:31:28.419926Z Till Kamppeter</strong></p> <blockquote> <pre> -In the event that we've decided not to cache a glyph generated by FAPI, we -need to make sure that zsetcachedevice2() doesn't opt to try to cache said -glyph. To do that we were setting in_cachedevice to CACHE_DEVICE_NOT_CACHING -before calling zchar_set_cache(), and setting it back to its previous value -on return. Unfortunately, a font with a CDevProc causes the call to -zsetcachedevice2() to be delayed until after execution of the CDevProc, so -in_cachedevice was (probably) no longer set to CACHE_DEVICE_NOT_CACHING. - -Amongst other effects, this caused some anti-aliased glyphs to be render -with incorrect, scaling as well as the potential for marking glyphs to have -empty (but valid) cached bitmaps. +Added color management support to the CUPS ...toraster filters -Expected cluster differences: fts_23_2306.pdf at 72dpi shows some (benign) -pixel differences on the pattern filled glyphs - this is actually a behaviour -progression, as it is caused by cache being properly bypassed for an uncached -glyph, rather than the glyph being rendered uncached but the cache receiving -an emtpy glyph. +Replaced the ...toraster filters by one filter executable, gstoraster, +written in C. This filter converts both PostScript and PDF input into +the CUPS Raster format using Ghostscript with the "cups" output +device, controlled by settings in the print queue's PPD file, by +command line options, and by settings embedded in a PostScript input +stream. This is now done with color management based on +printer-specific ICC profiles referenced in the PPD file or supplied +by the color management daemon colord. The CUPS PPD extensions +concerning color management +(http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html) are made +use of if used and the colord daemon is used if it is present. colord +is accessed via D-Bus, but the new filter can also be compiled without +D-Bus and in this case only the CUPS PPD extensions and ICC profiles +assigned to the print queue are used for color management. -Bug 691750. +Thanks to Richard Hughes for the patch. </pre> -<p>[psi/zfapi.c]</p> +<p>[cups/pstoraster.in cups/pstoraster.convs cups/gstoraster.c cups/pdftoraster.c cups/cups.mak base/Makefile.in cups/colord.c base/configure.ac cups/gstoraster.convs cups/pdftoraster.convs cups/colord.h]</p> </blockquote> -<p><strong><a name="2010-11-04T191308.201769Z"></a> -2010-11-04T19:13:08.201769Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-28T203043.994348Z"></a> +2011-02-28T20:30:43.994348Z Robin Watts</strong></p> <blockquote> <pre> -Increase in curve size to enable sharper cut offs (i.e. no interpolation of curve points) for thresholding profiles. </pre> -<p>[toolbin/color/icc_creator/ICC_Creator/icc_create.cpp]</p> -</blockquote> +X offset in custom 24 -> 888 planar copy_color routine was being miscalculated. +Simple fix. -<p><strong><a name="2010-11-03T204407.993086Z"></a> -2010-11-03T20:44:07.993086Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix to avoid potential crash instead of error if an improper file name is given for the device ICC profile.</pre> -<p>[base/gsicc_manage.c]</p> -</blockquote> - -<p><strong><a name="2010-11-02T171624.985382Z"></a> -2010-11-02T17:16:24.985382Z Chris Liddell</strong></p> -<blockquote> -<pre> -Remove some unnecessary, and detrimental endian related code -in the GS/lcms interface. - -Bug 691696 - -No cluster differences expected. - -</pre> -<p>[base/gsicc_cache.c base/gsicc_littlecms.c]</p> +No cluster differences expected as this is untested.</pre> +<p>[base/gdevmpla.c]</p> </blockquote> -<p><strong><a name="2010-11-01T235927.933765Z"></a> -2010-11-01T23:59:27.933765Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-28T193534.539587Z"></a> +2011-02-28T19:35:34.539587Z Robin Watts</strong></p> <blockquote> <pre> -Performance fix so that the md5 code is not used to hash the rendering conditions for the icc link. </pre> -<p>[base/gsicc_cache.c base/gscms.h]</p> -</blockquote> +Remove silly debugging hack left in gdevmpla.c by accident. Only affects +planar 888 devices (i.e. none enabled by default). -<p><strong><a name="2010-10-31T032619.022477Z"></a> -2010-10-31T03:26:19.022477Z Ray Johnston</strong></p> -<blockquote> -<pre> -Optimize large allocations in the chunk memory manager maintaining separate lists -for chunks with only a single block (that will never have any free space) from -the multiple object chunks which are searched for free space when the requests -are for small objects. Testing with a 28 files benchmark suite shows improvements -against rev 11876 by over 9% (real time), to get within 2% of version 8.71. -(testing 600 dpi ppmraw to /dev/null on peeves). -</pre> -<p>[base/gsmchunk.c]</p> +No cluster differences expected.</pre> +<p>[base/gdevmpla.c]</p> </blockquote> -<p><strong><a name="2010-10-30T034036.798714Z"></a> -2010-10-30T03:40:36.798714Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-28T193237.270892Z"></a> +2011-02-28T19:32:37.270892Z Robin Watts</strong></p> <blockquote> <pre> -Check for negative object nunbers and consider such objects as null. -Bug 691740, customer 384. -</pre> -<p>[Resource/Init/pdf_base.ps]</p> +Add simple .gitignore files.</pre> +<p>[.gitignore /trunk/ghostpdl/.gitignore]</p> </blockquote> -<p><strong><a name="2010-10-29T234030.279741Z"></a> -2010-10-29T23:40:30.279741Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-28T104811.852106Z"></a> +2011-02-28T10:48:11.852106Z Ken Sharp</strong></p> <blockquote> <pre> -Fix so that the image clues array is dynamically allocate only when needed as opposed to being a static array in gx_image_enum. clues is used only in the case of monochrome or indexed with bps <= 8 and masked images. Another optimization to do is to make it allocate only 2 entries for the masked case rather than all 256.</pre> -<p>[base/gxipixel.c base/gxidata.c base/gximage.h]</p> +Silence a compiler (scan-build) warning about a variable never being used.</pre> +<p>[base/gdevpdfo.c]</p> </blockquote> -<p><strong><a name="2010-10-29T193548.071618Z"></a> -2010-10-29T19:35:48.071618Z Henry Stiles</strong></p> +<p><strong><a name="2011-02-28T052346.157854Z"></a> +2011-02-28T05:23:46.157854Z Michael Vrhel</strong></p> <blockquote> <pre> -Revision 10823 removed an optimization to strength reduce the logical -operation when rendering an image - the optimization in fact was -incorrect (see the bug referenced in the commit entry #691147) however -the optimization is correct and gives us a good speedup if the current -color is black. This is due to the peculiarities of the pcl -transparency model which only effects the opacity/transparency of -white. -</pre> +Fix for mis-scale on decode for render mono cache. Fixes improper rendering of 148-11.ps with new halftone code.</pre> <p>[base/gxipixel.c]</p> </blockquote> -<p><strong><a name="2010-10-29T163741.020300Z"></a> -2010-10-29T16:37:41.020300Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Added features and fixed bugs to enable creation of thresholding ICC profiles.</pre> -<p>[toolbin/color/icc_creator/ICC_Creator/icc_create.h toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h toolbin/color/icc_creator/ICC_Creator/resource.h toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc toolbin/color/icc_creator/ICC_Creator/icc_create.cpp toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp]</p> -</blockquote> - -<p><strong><a name="2010-10-29T090542.895454Z"></a> -2010-10-29T09:05:42.895454Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix : DeviceN not permitting multiple identical inks - -Bug #691740 - -The DeviceN checking code did not permit multiple inks to have the same name. The -comment in the code says this is not permitted, but I am unable to find any -documentation in any of the specifications in support of this, and other interpreters -(including CPSI) do not make this restriction. - -Restriction removed, and also the 'continuation' procedures used for much of the colour -space parsing/validation have been given names so that future error messages use these -instead of printing the function address. - -No differences expected. -</pre> -<p>[base/gscdevn.c psi/zcolor.c]</p> -</blockquote> - -<p><strong><a name="2010-10-28T204114.761110Z"></a> -2010-10-28T20:41:14.761110Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-27T232610.406657Z"></a> +2011-02-27T23:26:10.406657Z Michael Vrhel</strong></p> <blockquote> <pre> -Addition in profile creation tool to create Gray ICC profiles with abrupt thresholds. Needed for solution to bug 691737</pre> -<p>[toolbin/color/icc_creator/ICC_Creator/icc_create.h toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.h toolbin/color/icc_creator/ICC_Creator/resource.h toolbin/color/icc_creator/ICC_Creator/ICC_Creator.rc toolbin/color/icc_creator/ICC_Creator/icc_create.cpp toolbin/color/icc_creator/ICC_Creator/ICC_CreatorDlg.cpp]</p> +Removal (or inactivation) of code to include inverse of transfer function in the threshold values. Also minor fix for scaling issue in halftone code in portrait mode. Code is inactive so no regression diffs expected.</pre> +<p>[base/gximono.c base/gsht.c]</p> </blockquote> -<p><strong><a name="2010-10-28T195751.569853Z"></a> -2010-10-28T19:57:51.569853Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-27T232330.287293Z"></a> +2011-02-27T23:23:30.287293Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix for issues that arise when the embedded icc profile is the same as one of the default icc profiles and we are using pdfwrite. This should fix 691731.</pre> -<p>[base/gsicc_create.c base/gsicc_manage.c base/gscms.h base/gsciemap.c]</p> -</blockquote> - -<p><strong><a name="2010-10-28T190245.723574Z"></a> -2010-10-28T19:02:45.723574Z Robin Watts</strong></p> -<blockquote> -<pre> -Marcos points out that tiffscaled with -rR -dDownScaleFactor=D can produce -different sized images than just using -r(R*D) and a normal tiff device. -(Bug 691730). I'll concede he's probably right that this isn't ideal. - -The difference was caused by me rounding the size up on a downscale so that -no information is lost. - -This patch removes the rounding up. We can always add it again later if -we actually find a file where it makes a difference. - -No expected cluster differences. - -</pre> -<p>[base/gdevtifs.c]</p> -</blockquote> - -<p><strong><a name="2010-10-28T150037.200667Z"></a> -2010-10-28T15:00:37.200667Z Chris Liddell</strong></p> -<blockquote> -<pre> -Work around the "no rule to make target" with tif_config.h (actually it -affects tiffconf.h, too). This involves the rather unpleasant requirement -of calling a configure script (for libtiff) from a makefile (the top level -makefile for the ghostpdl builds). It must be done there, before the PDL -specific makefiles start setting CFLAGS, which confuses the configure. - -Also, update the GS dist-clean and GhostPDL clean targets to remove -the two tiff header files generated during the tiff configure. - -THIS IS NOT A FIX! It really is a "workaround". - -Bug 691700. - - -</pre> -<p>[/trunk/ghostpdl/Makefile base/Makefile.in]</p> -</blockquote> - -<p><strong><a name="2010-10-28T061253.429268Z"></a> -2010-10-28T06:12:53.429268Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Code to speed up cases where a file contains a lot of small images that are embedded in the clist as high level images. Previously, for every high level image, the serialized ICC source data was read out of the clist at a different clist file location, which required a fseek, a fread and then another fseek. This occurred even if all the images shared the same profile. The cost of file i/o for this can become significant if we have a lot of images. With this commit, the reading of the profile data is delayed and will only occur if a link using that profile does not already exist in the link cache. </pre> -<p>[base/gxclpath.c base/gxclimag.c base/gxclist.h base/gxclrast.c]</p> -</blockquote> - -<p><strong><a name="2010-10-28T041255.507828Z"></a> -2010-10-28T04:12:55.507828Z Marcos H. Woehrmann</strong></p> -<blockquote> -<pre> -Added dependencies to devs.mak to allow minftrsz.c to compile with concurrent make. - -</pre> -<p>[base/devs.mak]</p> -</blockquote> - -<p><strong><a name="2010-10-27T233042.045125Z"></a> -2010-10-27T23:30:42.045125Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix compiler warning. - -No expected differences. - -</pre> -<p>[base/gdevtifs.c]</p> -</blockquote> - -<p><strong><a name="2010-10-27T194801.087645Z"></a> -2010-10-27T19:48:01.087645Z Robin Watts</strong></p> -<blockquote> -<pre> -Add new version of tiffscaled device, that supports -dMinFeatureSize=2. -(Solves bug 691718). - -Also add support for AdjustWidth in tiffscaled device. - -Also update documentation. - -No expected differences. - -</pre> -<p>[base/gdevfax.h base/gdevtifs.c base/minftrsz.c base/gdevtifs.h base/gdevtsep.c base/minftrsz.h doc/Devices.htm base/gdevfax.c base/gdevtfnx.c base/gdevtfax.c]</p> -</blockquote> - -<p><strong><a name="2010-10-27T124549.361211Z"></a> -2010-10-27T12:45:49.361211Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix Bug 691727. - -Black and White Tiff based devices were not respecting the AdjustWidth -parameter. Fax based devices were applying it regardless, non faxed based -devices were not applying it at all. The documentation says they should -all default to applying it, but be controlled by the option. - -In this commit, we change so that all black and white tiff based devices -(except tiffscaled) respect this parameter. We default to applying it in -fax devices, and not applying it in non-fax devices, so default behaviour -does not change. We also update the docs. - -No expected differences. - -</pre> -<p>[doc/Devices.htm base/gdevtfax.c]</p> -</blockquote> - -<p><strong><a name="2010-10-27T111838.076346Z"></a> -2010-10-27T11:18:38.076346Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix Bug 691726, memory corruption in tiffscaled device when -(resolution % DownScaleFactor) != 0. - -The problem specifically occurred when the page had 'stray' lines at the end. -The code I had written to cope with this was calling the Tiff writing code -with the wrong row number, causing the tiff lib to try to extend the buffer. -This, it seems, is a bad thing. - -The miscalculation is fixed here, and the bug goes away. - -No expected cluster differences. - -</pre> -<p>[base/gdevtifs.c]</p> -</blockquote> - -<p><strong><a name="2010-10-26T235413.691521Z"></a> -2010-10-26T23:54:13.691521Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix bug reported by Norbert Janssen. Inaccuracies in the floating point maths -can cause 'no-scales' to look like 'downscales', and so high level images are -skipped. - -This shouldn't actually matter in most cases as the two rendering paths should -give the same results, but when people hook the clist for their own purposes -this can cause problems. The workaround is to introduce a fudge factor and to -accept very slight downscales. - -Thanks to Norbert for the first version of this patch. - -Minimal differences in cluster testing due to bug 691697. - - -</pre> -<p>[base/gxclimag.c]</p> -</blockquote> - -<p><strong><a name="2010-10-26T203032.970049Z"></a> -2010-10-26T20:30:32.970049Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for RGB byte order expected by new CMM compared to imdi libray.</pre> -<p>[base/gdevwts.c]</p> -</blockquote> - -<p><strong><a name="2010-10-26T202245.373077Z"></a> -2010-10-26T20:22:45.373077Z Robin Watts</strong></p> -<blockquote> -<pre> -Silence gcc warning. - -</pre> -<p>[base/gdevfax.c]</p> +Fix for a bug that was introduced with the ICC branch. This was causing a mismatch between banded an unbanded rendering and in particular had rendering errors in banded mode when rendering PS and PDF files that had a non identity transfer function. Minor progression diffs in many files with very visible progressions in 246-01.ps, 258-01.ps as examples. What was happening is that when running in clist mode, we were not recognizing that a transfer function was present when doing the ICC branch. Stumble upon this working the transfer function in with the new threshold based halftoning code.</pre> +<p>[base/gxipixel.c]</p> </blockquote> -<p><strong><a name="2010-10-26T194135.752819Z"></a> -2010-10-26T19:41:35.752819Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-27T015228.834714Z"></a> +2011-02-27T01:52:28.834714Z Ray Johnston</strong></p> <blockquote> <pre> -Removal of accidental commit of my own path for the wts halftone planes. - +Fix for PDF with ASCII85Decode filter that has a dictionary (even if empty) +instead of a 'null' for the params. Stack has the param dict second on the +stack, not third. Bug 692003, customer 700. </pre> -<p>[base/gdevwts.c]</p> -</blockquote> - -<p><strong><a name="2010-10-26T185049.267717Z"></a> -2010-10-26T18:50:49.267717Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that wtsimidi device works again. I had the device using the wrong structure for maintaining its device link that maps the contone RGB data to CMYK.</pre> -<p>[base/gdevwts.c]</p> +<p>[Resource/Init/pdf_base.ps]</p> </blockquote> -<p><strong><a name="2010-10-26T181015.277289Z"></a> -2010-10-26T18:10:15.277289Z Robin Watts</strong></p> +<p><strong><a name="2011-02-26T191752.838303Z"></a> +2011-02-26T19:17:52.838303Z Till Kamppeter</strong></p> <blockquote> <pre> -Add Rays MinFeatureSize magic. Ray had originally integrated this into the -fax devices, which had the effect of working for the tiff based fax -devices too. Unfortunately the reworking of the tiff based devices to -use libtiff meant that the output function changed, causing the patch to -stop working with those devices. - -Here we split the new code out into a separate .c/.h pair, so it can be -used by both tiff and fax devices, and hook it up to all the black and -white tiff devices (except tiffscaled) and to the fax based ones. - -We also document the device (including it's current limitations). - -No expected changes. +TCUPS Raster driver: The macros in the cups_put_params() function +could access uninitialized variables when logging error messages and +this could lead to a segmentation fault, making Ghostscript crashing +and many jobs not printed. Debian bug #615202. </pre> -<p>[base/gdevfax.h base/gdevtifs.c base/minftrsz.c base/gdevtifs.h ghostscript.vcproj base/minftrsz.h base/gdevtsep.c doc/Devices.htm base/gdevfax.c base/gdevtfnx.c base/devs.mak base/gdevtfax.c]</p> +<p>[cups/gdevcups.c]</p> </blockquote> -<p><strong><a name="2010-10-26T141424.874268Z"></a> -2010-10-26T14:14:24.874268Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-26T184059.351498Z"></a> +2011-02-26T18:40:59.351498Z Ray Johnston</strong></p> <blockquote> <pre> -Generate fully opaque mask when /SMaskInData attribute is specified in PDF -but JPX stream has no opacity channel. Fix the case of missing images on -Luratech decoder in fts_17_1717.pdf and fts_17_1718.pdf. +Fix for PDF 1.7 fts_08_0808.pdf which can clip the corner of the really wide +diagonal (magenta) stroke when banding is used. This was due to the 'extension' +of a square line cap being incorrectly calculated. Customer 532 issue. </pre> -<p>[base/sjpx_luratech.c]</p> +<p>[base/gxstroke.c]</p> </blockquote> -<p><strong><a name="2010-10-25T165126.885213Z"></a> -2010-10-25T16:51:26.885213Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-26T182508.170267Z"></a> +2011-02-26T18:25:08.170267Z Ray Johnston</strong></p> <blockquote> <pre> -Change the interface to Luratech JPX library to extract image data or -opacity depending on the alpha parameter. +Fix BUILD_SYSTEM conditional for 64 vs. 32 and add 'for Win64' message +to help avoid confusion during setup. </pre> -<p>[base/sjpx_luratech.c]</p> +<p>[psi/winint.mak]</p> </blockquote> -<p><strong><a name="2010-10-25T155910.973330Z"></a> -2010-10-25T15:59:10.973330Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-25T235750.833144Z"></a> +2011-02-25T23:57:50.833144Z Robin Watts</strong></p> <blockquote> <pre> -Fix pdfwrite : Do not emit DeviceRGB/CMYK as an Alternate when disallowed by PDF/A or X +Fix bug reported by "new customer feb 2011", whereby gs 8.71 on an embedded +ppc platform is getting the colours on an image in a pdf wrong. -If a /Separation colour space had an /Alternate of /DeviceRGB or DeviceCMYK it was not -checked to see if it was valid for PDF/A or PDF/X production, if these were set. +Debugging shows that in gs_indexed_limit_and_lookup we take a floating point +value, clip it, convert it to an int and use it to lookup which colour to use. +On the reference x86 run we have a value of 1 (0x3f800000 as an IEEE float). +On the ppc we have 0.999999 (0x3f7fffff as an IEEE float). This tiny difference +results in values of 1 and 0 respectively when converted to the int, giving +the wrong colour. -As a result invalid PDF/A or PDF/X files could be written. +The fix here is to add a small epsilon before conversion. -The code now tests these flags and if the base space is not valid, converts to an -appropriate base space by; sampling the tint transform function at 0 and 1, converting -the resulting colours to the appropriate base space (using the Red Book methods for -DeviceRGB/DeviceCMYK conversion), creating a new linear interpolation function for -the new base space, using the converted sampled values for /Co and C1. +A quick experiment in adding 0.5 rather than epsilon shows worse results. -The new base space is then written to the PDF file. +15 cluster differences in testing, none that actually survived a bmpcmp. -No differences expected as we don't test PDF/A and PDF/X on the cluster.</pre> -<p>[base/gdevpdfc.c]</p> -</blockquote> -<p><strong><a name="2010-10-25T062322.846885Z"></a> -2010-10-25T06:23:22.846885Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Move initialization of state->alpha flag to the place where it has effect. </pre> -<p>[base/sjpx_luratech.c]</p> +<p>[base/gscolor2.c]</p> </blockquote> -<p><strong><a name="2010-10-25T043951.229054Z"></a> -2010-10-25T04:39:51.229054Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-25T194939.160812Z"></a> +2011-02-25T19:49:39.160812Z Michael Vrhel</strong></p> <blockquote> <pre> -Merge rev. 11790, 11795, 11802, 11805, 11809, 11810, 11812, 11813, 11818 -into the trunk. JPX files without SMaskInData are now rendered correctly. -Other JPX files are rendered incorrectly. Trunk PostScript code and Jasper -use separate access to opacity and data. Luratech is still using pixel- -interleaved format. -</pre> -<p>[base/sjpx_luratech.c base/sjpx_luratech.h psi/msvc32.mak]</p> +Fix so that we only do the fast code if we are in portrait or landscape mode. Skewed objects will have to use the rect fill method.</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-10-25T041646.177854Z"></a> -2010-10-25T04:16:46.177854Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-25T193355.727547Z"></a> +2011-02-25T19:33:55.727547Z Michael Vrhel</strong></p> <blockquote> <pre> -Rev. 11785 have introduced double decrement of the reference counter in -gx_pattern_cache_free_entry() that caused warnings with -Z? option and -SEGV on Windows, esp. with Luratech JPX library. This patch resolves -all warnings and crashes. Bug 691714. -</pre> -<p>[base/gxpcmap.c]</p> +Addition of code to incorporate the inverse of the transfer curve into the threshold matrix. If the curve is an inverting type (e.g. 0 to 1 and 1 to 0) then a the thresholding comparison is switched. Also, if the curve is not monotonic, it can not be inverted and we revert to the old rect fill method. This commit has the code disabled so there should not be any regressions.</pre> +<p>[base/lib.mak base/gximono.c base/gzht.h base/gxdht.h base/gsht.c]</p> </blockquote> -<p><strong><a name="2010-10-24T222355.448411Z"></a> -2010-10-24T22:23:55.448411Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-25T181349.002375Z"></a> +2011-02-25T18:13:49.002375Z Ray Johnston</strong></p> <blockquote> <pre> -Implement /SMaskInData using images with /SMask and separate streams for the -mask and image data. Our /ImageType 103 seems to have issues and cannot be -used directly. /JPXDecode filter now takes /Alpha parameter, which controls -whether opacity or image data stream is extracted. - -This commit introduces a PS error on pdfwrite device in fts_18_1805.pdf -and a few other files with the same image. However, this image has never -been combined with SMask before and the actual bug may predate the commit. -Bug 691489, customer 532. +Set the GS_DLL to gsdll64.dll for a 64-bit build. The file list was correct, +but the registry was not. Related to bug 691975 but not verified (I just +checked the registry using regedit). </pre> -<p>[base/sjpx.c Resource/Init/pdf_draw.ps]</p> +<p>[psi/dwsetup.cpp]</p> </blockquote> -<p><strong><a name="2010-10-23T223817.069244Z"></a> -2010-10-23T22:38:17.069244Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-25T074221.024741Z"></a> +2011-02-25T07:42:21.024741Z Chris Liddell</strong></p> <blockquote> <pre> -Move checking for /JPXDecode filter in front of checking for missing color -spaces to handle /SMaskInData attribute in all cases. Fix handling of filter -arrays and a wrong name /DecodeParms. -</pre> -<p>[Resource/Init/pdf_draw.ps]</p> -</blockquote> +Revise how the UFST setting are handled in the makefiles. -<p><strong><a name="2010-10-22T092910.157074Z"></a> -2010-10-22T09:29:10.157074Z Chris Liddell</strong></p> -<blockquote> -<pre> -Add a debug-clean target (which in turn calls the existing debugclean target) -to be more consistent with the ghostpdl langauge builds. +The previous version relied on GNU make extensions (specifically +conditionals), whilst this version does not. No cluster differences expected. </pre> -<p>[base/Makefile.in]</p> -</blockquote> - -<p><strong><a name="2010-10-22T075212.054756Z"></a> -2010-10-22T07:52:12.054756Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove a spurious space that was causing a compiler warning, and remove an unused -function, also causing a compiler warning. -</pre> -<p>[base/gdevpdfu.c]</p> +<p>[base/lib.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p> </blockquote> -<p><strong><a name="2010-10-22T063849.083740Z"></a> -2010-10-22T06:38:49.083740Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-24T111312.751072Z"></a> +2011-02-24T11:13:12.751072Z Chris Liddell</strong></p> <blockquote> <pre> -Make oforce_recursive more robust in preparation to SMaskInData commit. -Don't execute tint transform functions and similar executable arrays -that may be added by our PDF interpreter to PDF objects. -</pre> -<p>[Resource/Init/pdf_base.ps]</p> -</blockquote> +Hopefully the final iteration of allowing SHARE_ZLIB +to work correctly with COMPILE_INITS=1. -<p><strong><a name="2010-10-22T041930.192593Z"></a> -2010-10-22T04:19:30.192593Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Recognize /SMaskInData attribute as an indicator that the page has -transparency features. Establish a base level for a future regression -testing. -</pre> -<p>[Resource/Init/pdf_main.ps]</p> -</blockquote> +This version changes only Unix-like builds, so Windows need +not suffer, and also removes the reliance GNU make specific +extensions. -<p><strong><a name="2010-10-21T155737.250433Z"></a> -2010-10-21T15:57:37.250433Z Ken Sharp</strong></p> -<blockquote> -<pre> -More DSC work. Altered Procset emission to strip comments (but not line endings), as -some of the ProcSets included %%BeginPrologue and %%EndPrologue comments which isn't -(I don't think) allowed. Also makes the output file smaller. - -When producing DSC output, don't set the FitPages/RoatePages/CenterPages/SetPageSize -operations. - -Don't permit the entire file to be compressed when emitting DSC PostScript -(clearly won't be DSC compliant that way) - -Produce some very basic DSC Comments; the correct header, %%Pages, %%Beginprologue. -%%EndPrologue, %%EndComments. +Bug 691986 + -Don't emit %PDF header when producing DSC PostScript. +No cluster differences. -Count the number of pages and emit a %%Pages: comment at the end of the file. Don't -write the Info dict when producing DSC PostScript. Emit %%Trailer and $$EOF. </pre> -<p>[base/gdevpdf.c base/gdevpdfu.c]</p> +<p>[base/unix-aux.mak]</p> </blockquote> -<p><strong><a name="2010-10-21T140927.225155Z"></a> -2010-10-21T14:09:27.225155Z Marcos H. Woehrmann</strong></p> +<p><strong><a name="2011-02-24T005108.210054Z"></a> +2011-02-24T00:51:08.210054Z Robin Watts</strong></p> <blockquote> <pre> -Updated the cluster new node instructions to test the cups device -when verifying the installation is complete. - -</pre> -<p>[toolbin/localcluster/readme]</p> -</blockquote> +Add new plib family of devices (PLanar Interlaced Buffer). These 5 devices +(plib = r8g8b8, plibg = g8, plibm = mono, plibc = c8m8y8k8, plibk = c1m1y1k1) +use a new 'band donor' interface to request a band buffer, pass back +rendered bands, and release bands at the end of the page. -<p><strong><a name="2010-10-21T133900.821724Z"></a> -2010-10-21T13:39:00.821724Z Marcos H. Woehrmann</strong></p> -<blockquote> -<pre> -Added the cups dev repositories to the cluster node sertup read.me +The idea is that other firmware can implement this simple interface, and +Ghostscript can thus easily drive systems that expect planar interlaced +input. -</pre> -<p>[toolbin/localcluster/readme]</p> -</blockquote> +On the whole there is relatively little new code here; the majority of the +work is done using the existing planar device with the odd tweak here and +there. Firstly, we lift the (artifical) constraints of the number of components +supported (so greyscale is accepted as a planar device for simplicity). +We spot the num_components = 1 case and just use the existing memory device +interface. -<p><strong><a name="2010-10-21T111731.420556Z"></a> -2010-10-21T11:17:31.420556Z Ken Sharp</strong></p> -<blockquote> -<pre> -When producing DSC compliant PostScript from ps2write, do not emit the following; -Pages tree, outlines, articles, named destinations, PageLabels array, document metadata, -document Catalog, threads, encrypt dictionary, xref, trailer. +Secondly, we add a fast 888chunky to 888planar unpacking routine for use +with copy_color. -These objects are not required by PostScript, and cannot be easily -placed in a DSC-conforming file. This does mean that, unlike the general output from -ps2write, the output file is *not* a valid PDF file and cannot be opened as such by a -PDF consumer. +Within the plib device itself, we make use of the facility to set the line +indexes to allow for interlaced operation. It would be easy to extend this +device to offer planar non-interlaced operation too built on the same band +donor interface simply by omitting this code. -No differences expected. -</pre> -<p>[base/gdevpdf.c]</p> -</blockquote> +For debugging purposes we have options within the plib devices to store the +data returned in each band into pxm files (as appropriate to the number of +components). This code is deactivated by default as the output of this +device is via the band donor interface, not the output file. -<p><strong><a name="2010-10-21T110740.293085Z"></a> -2010-10-21T11:07:40.293085Z Ken Sharp</strong></p> -<blockquote> -<pre> -Correct a bug in revision 11828 which tried to copy too many bytes from the source -buffer, if fewer bytes were read then were requested, when copying a ProcSet. -</pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> +No cluster differences expected as this code is disabled currently. -<p><strong><a name="2010-10-21T082247.321512Z"></a> -2010-10-21T08:22:47.321512Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove some unused variables to silence compiler warnings. -</pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> +Next job: discuss with Marcos how to cluster test this. -<p><strong><a name="2010-10-21T024848.797956Z"></a> -2010-10-21T02:48:48.797956Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Don't search for a font named / on disk, because operator findlibfile -throws an error in this case. Just fail the request when such font is -not defined in VM. Bug 691698, customer 384. </pre> -<p>[Resource/Init/gs_res.ps]</p> +<p>[base/gdevplib.c base/gdevmpla.c base/gdevplib.h base/gdevppla.c base/devs.mak]</p> </blockquote> -<p><strong><a name="2010-10-20T170027.929678Z"></a> -2010-10-20T17:00:27.929678Z Robin Watts</strong></p> +<p><strong><a name="2011-02-23T160025.505362Z"></a> +2011-02-23T16:00:25.505362Z Robin Watts</strong></p> <blockquote> <pre> -Add a helpful valgrind header, and call it from gsmdebug.h. - -The valgrind header here serves 2 purposes. - -Firstly, it insulates us from platforms on which Valgrind does not exist - -if we build without defining ENABLE_VALGRIND then no dependency on any -valgrind headers exists. The standard Valgrind macros are all defined in -this header to do nothing, so they can safely be called in our code -without needing ugly #ifdef ENABLE_VALGRIND wrapping. +Introduce and enable 8 bit rop run templated code. -Secondly, it insulates us from changes in the valgrind/memcheck.h file - -if ENABLE_VALGRIND is defined we will use whatever version is defined by -the system. If new macros are defined by new versions of valgrind/memcheck.h -we simply need to add new 'empty' definitions to valgrind.h. - -To start with, the only use of this code is to mark the contents of newly -allocated blocks as being undefined. Thanks to AlexCher for spotting a -cunning place to do this. +No cluster differences shown. </pre> -<p>[base/valgrind.h base/gsmdebug.h]</p> +<p>[base/gsroprun8.h base/lib.mak base/gsroprun.c ghostscript.vcproj]</p> </blockquote> -<p><strong><a name="2010-10-20T165951.575415Z"></a> -2010-10-20T16:59:51.575415Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-23T144145.053687Z"></a> +2011-02-23T14:41:45.053687Z Michael Vrhel</strong></p> <blockquote> <pre> -Add /ZapfDingbats to the list of known symbolic fonts, which ignore bogus -/Encoding attribute. Fix fts_23_2300.pdf rendering. -</pre> -<p>[Resource/Init/pdf_font.ps]</p> +Remove commented out code left over from commit 12192</pre> +<p>[base/lib.mak]</p> </blockquote> -<p><strong><a name="2010-10-20T160528.326890Z"></a> -2010-10-20T16:05:28.326890Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-23T115400.145784Z"></a> +2011-02-23T11:54:00.145784Z Robin Watts</strong></p> <blockquote> <pre> -Initial work on DSC compliant PostScript. When ProduceDSC is true, do not strip the -ProcSet, this is because DSC-compliant files have a line limit of 256. Later we will -want to wrap the ProcSet emissions with %%BeginResource/%%EndResource as well. - -No effect if ProduceDSC is not true, so no differences expected. -</pre> -<p>[base/gdevpdfu.c]</p> -</blockquote> +Reintroduce runrop changes to Visual Studio solution lost in recent merge +(r12189). -<p><strong><a name="2010-10-20T144548.119859Z"></a> -2010-10-20T14:45:48.119859Z Ken Sharp</strong></p> -<blockquote> -<pre> -Add a new switch to ps2write, working title 'ProduceDSC'. This will be used to control -whether the output of ps2write is DSC-compliant or not. +No cluster differences expected. -No differences expected. </pre> -<p>[base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]</p> +<p>[ghostscript.vcproj]</p> </blockquote> -<p><strong><a name="2010-10-20T105923.603495Z"></a> -2010-10-20T10:59:23.603495Z Robin Watts</strong></p> +<p><strong><a name="2011-02-23T082540.039813Z"></a> +2011-02-23T08:25:40.039813Z Chris Liddell</strong></p> <blockquote> <pre> -Disable the use of high level images in the clist if we are downscaling; -this serves 2 purposes. - -Firstly, it fixes the potential problems with banded/unbanded mismatch -of rendering due to the 'support' calculations done in the high level image -code. These calculations are no longer correct for downscales since the -change to use a simpler interpolated image scaler. - -Secondly, when downscaling we will probably end up copying more data than -we would if we just kept the original, so high level images are a bad idea -anyway. - -This *should* produce no differences, but actually produces lots. - -Most of these might be ignorable (slight rendering differences that appear to -result in the new images being a little lighter, but a significant number -appear to be noticable progressions, which hints that the high level image -clist code is broken. Specifically high level images fail to render the -same as the non high level code does. In particular halftoning seems to -be enabled for some examples when high level images are used, for no good -reason. This has been opened as bug 691697. +Revision to the changes for using the system zlib. +r12184 caused problems on Windows. -</pre> -<p>[base/gxclimag.c]</p> -</blockquote> +This approach uses configure to determine whether +freetype should use the system zlib, based on whether +Ghostscript is using the system zlib. -<p><strong><a name="2010-10-20T102150.512085Z"></a> -2010-10-20T10:21:50.512085Z Robin Watts</strong></p> -<blockquote> -<pre> -Unpack a hideously complex if statement into a series of if statements. -Any reasonable compiler (if such a thing can be said to exist) should -compile to the same code, but this is a lot easier to use under a debugger/ -read. +Windows, of course, doesn't use configure, so it will +never attempt to the use the system zlib. -No changes expected in testing (and clusterpush agrees). +Bug 691986 +No cluster differences expected </pre> -<p>[base/gxclimag.c]</p> +<p>[base/freetype.mak base/Makefile.in base/configure.ac]</p> </blockquote> -<p><strong><a name="2010-10-19T080432.778817Z"></a> -2010-10-19T08:04:32.778817Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-23T032618.063337Z"></a> +2011-02-23T03:26:18.063337Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Update CFF interpreter to handle gsubr while searching for SEAC - -Bug #691680 "PDF Writer drops many accented characters" - -pdfwrite makes use of a routine 'gs_type1_piece_codes' while copying fonts to determine -if a glyph is a SEAC, and therefore includes two subsidiary glyphs. This code was -updated previously (rev 10076) but on encountering a callgsubr in a CFF font, assumed -that the glyph was not a SEAC> - -This patch adds support for callgsubr and continues searching glyphs which use a gsubr -to see if the gsubr is actually a SEAC type endchar. - -No differences expected. -</pre> -<p>[base/gxtype1.c]</p> +Temporary fix to turn off fast code for cases where the bps of the index image is not 8bps</pre> +<p>[base/gximono.c]</p> </blockquote> -<p><strong><a name="2010-10-18T154420.143696Z"></a> -2010-10-18T15:44:20.143696Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-23T010908.645858Z"></a> +2011-02-23T01:09:08.645858Z Michael Vrhel</strong></p> <blockquote> <pre> -Silence a compiler warning from my previous commit. - -</pre> -<p>[psi/zchar42.c]</p> +Undo of rev 12184 by commenting out the changes for now. This change broke the windows build. </pre> +<p>[base/lib.mak]</p> </blockquote> -<p><strong><a name="2010-10-18T141144.566085Z"></a> -2010-10-18T14:11:44.566085Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-22T213158.870907Z"></a> +2011-02-22T21:31:58.870907Z Robin Watts</strong></p> <blockquote> <pre> -In a CIDType2 font with a gsub table, when/if we substitute the glyph index -with an index for a vertical glyph, make sure we change the value of the -Truetype glyph index, and *not* the value of the Postscript CID. - -Bug 691692 +Fix warnings caused by merging the halftone branch to the trunk in r12189. No cluster differences expected. </pre> -<p>[psi/zchar42.c]</p> +<p>[base/gxipixel.c base/gximono.c base/gsht.c]</p> </blockquote> -<p><strong><a name="2010-10-16T155253.774342Z"></a> -2010-10-16T15:52:53.774342Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-22T200337.651092Z"></a> +2011-02-22T20:03:37.651092Z Robin Watts</strong></p> <blockquote> <pre> -Fix pdfwrite: Don't use CFF font format if CompatibilityLevel < 1.2 +Forgot this file inthe last commit. Sorry! -We permit CompatibilityLevel down to 1.1, but PDF 1.1. doesn't support CFF (Type 1C) -fonts, so don't use this format if CompatibilityLevel < 1.2. - -No differences expected. </pre> -<p>[base/gdevpdfp.c]</p> +<p>[base/gsroprun24.h]</p> </blockquote> -<p><strong><a name="2010-10-15T151236.033471Z"></a> -2010-10-15T15:12:36.033471Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-22T195243.275685Z"></a> +2011-02-22T19:52:43.275685Z Michael Vrhel</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Scale up type 3 font outlines to give more accuracy - -Bug #691383, #691287, #691595 various type 3 font problems. - -Although this is being fixed for the FreeType implementation, the Artifex font -interpreter had similar problems. - -The issue is caused by using an identity scale at 72 dpi to capture font outlines. -Quark often uses a type 3 font which runs a type 1 font, in order to achieve text -special effects, such as stroke+fill. The stroke was achieved by a 'charpath/fill' -combination, because pdfwrite doesn't have a charpath, this meant that the path was -captured and emitted. Because the scale was so low, the interpreter could run out of -arithmetic precision, resulting in poorly formed outlines. - -We can't simply use the CTM in force at the time, as that includes the font scale, but -we need to use something other than the identity. A scale facto of 1000 proved too -likely to cause arithmetic overflow, or clipping, and also meant writing large values -to the PDF file, which is inefficient. A factor of 10 turned out to be insufficient, so -a factor of 100 has been used. - -Because the CharProc is effectively interpreted at the page level, this can result in -large values being used for paths, so we need to scale the device width and height by -100 as well, to prevent clipping (and undo it afterwards!) - -</pre> -<p>[base/gdevpdtt.c base/gdevpdti.c]</p> +Merge of halftone branch into the trunk. The new rendering code is actually disabled with this commit. As such, there should not be any testing differences.</pre> +<p>[base/gxipixel.c base/lib.mak base/Makefile.in base/gxcie.h /trunk/gs base/gsht.c base/gxcmap.c psi/msvc.mak ghostscript.vcproj base/gximono.c base/gzht.h base/gxidata.c base/configure.ac base/gxdht.h base/gxcmap.h base/gxicolor.c base/gximage.h base/gsciemap.c]</p> </blockquote> -<p><strong><a name="2010-10-15T150705.687999Z"></a> -2010-10-15T15:07:05.687999Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-22T193857.296889Z"></a> +2011-02-22T19:38:57.296889Z Robin Watts</strong></p> <blockquote> <pre> -With the latest release of Freetype, reinstate the "sensible" method of -limiting the size of the bitmap that we let Freetype create. It is -limited to 1.5x the current maximum cacheable glyph bitmap, as it is *vital* -that we avoid creating an outline when the cache expects a bitmap, -but not a problem if we create a bitmap for a non-cached glyph. - -Bug 691569. +Add templated 24bit rops. Clusterpushing seems to indicate this works. No cluster differences expected. </pre> -<p>[psi/fapi_ft.c]</p> -</blockquote> - -<p><strong><a name="2010-10-15T142151.952651Z"></a> -2010-10-15T14:21:51.952651Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Properly scale co-ordinates into Acrobat's range - -When emitting various co-ordinates pdfwrite is careful to stay within +/- 32,767 in -order to ensure all versions of Acrobat can properly deal with them. To achieve this it -emits a matrix which scales values up, and then writes the co-ordinates scaled down -by this factor. Thus ensuring that they stay within permitted values, but are still -correct. - -However, when emitting a rectangular fill, the scale was applied backwards, the -co-ordinates were scaled *up* instead of down by the scale factor. This led to wildly -incorrect values being written for rectangular paths. - -No differences expected with this in the test suite, however it forms part of the fix -for type 3 fonts which will follow and does rely on this change. -</pre> -<p>[base/gdevpdfd.c]</p> +<p>[base/lib.mak base/gsroprun.c base/gsroprun1.h]</p> </blockquote> -<p><strong><a name="2010-10-14T202315.984226Z"></a> -2010-10-14T20:23:15.984226Z Henry Stiles</strong></p> +<p><strong><a name="2011-02-22T161008.900201Z"></a> +2011-02-22T16:10:08.900201Z Chris Liddell</strong></p> <blockquote> <pre> -The image_set_gray function needed to take the address of the pointer -to the device color, the parameter should have been passed by -reference, as it must be set to &penum->clues[sample_value].dev_color -and returned. We'd like to get rid of the macro entirely and use the -image_set_gray as an inline function but have not tested performance. -The function might be too complex for inlining on some compilers. -</pre> -<p>[base/gximono.c]</p> -</blockquote> - -<p><strong><a name="2010-10-14T150601.276381Z"></a> -2010-10-14T15:06:01.276381Z Chris Liddell</strong></p> -<blockquote> -<pre> -In gx_alloc_char_bits() the "target" device can be NULL, in which case -avoid trying to decrement the ICC profile object for the target device. +Tweak to allow compressed romfs to be built when we're configured +to use the system's zlib rather than our own. -patch credit to William Bader. +As a side effect of this, freetype is now configured to use the +same zlib instance as Ghostscript (instead of freetype's own +subset of zlib sources). -Bug 691651. +Bug 691986 No cluster differences expected. </pre> -<p>[base/gxccman.c]</p> +<p>[base/freetype.mak base/lib.mak]</p> </blockquote> -<p><strong><a name="2010-10-14T150156.645831Z"></a> -2010-10-14T15:01:56.645831Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-22T154409.440053Z"></a> +2011-02-22T15:44:09.440053Z Robin Watts</strong></p> <blockquote> <pre> -If we're passed an unexpected object instead of a glyph name object -fall back to rendering the notdef. - -This is not identical, but is closer to the behaviour of the AFS code -under these conditions. - -Highlighted by Bug 691656. +Add new gsroprun files to Visual Studio solution. No cluster differences expected. </pre> -<p>[psi/zfapi.c]</p> +<p>[ghostscript.vcproj]</p> </blockquote> -<p><strong><a name="2010-10-14T145736.364971Z"></a> -2010-10-14T14:57:36.364971Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-22T152803.132855Z"></a> +2011-02-22T15:28:03.132855Z Robin Watts</strong></p> <blockquote> <pre> -Rename libpng.mak to png.mak to make it consistent with the other -third part libraries. +Fix DO_FILL_RECT_BY_COPY_ROP code, and enable it by default. -Bug 691681 +The only thing wrong with the code before is the case when strip_tile_rectangle +is called with both color0 and color1 being gx_no_color_index. That translates +to rop=0xAA (i.e. D - no change). This is actually a special case that means +it's really doing a copy_color operation. We handle this by punting in the +same way as the old code used to. No cluster differences expected. </pre> -<p>[base/openvms.mmk base/ugcclib.mak base/libpng.mak base/Makefile.in base/unix-gcc.mak base/macos-mcp.mak base/winlib.mak base/png.mak psi/os2.mak base/openvms.mak base/macosx.mak base/configure.ac /trunk/ghostpdl/common/ugcc_top.mak psi/msvc32.mak base/unixansi.mak base/msvclib.mak base/devs.mak]</p> +<p>[base/gdevm1.c]</p> </blockquote> -<p><strong><a name="2010-10-14T142322.009615Z"></a> -2010-10-14T14:23:22.009615Z Till Kamppeter</strong></p> +<p><strong><a name="2011-02-22T001816.845591Z"></a> +2011-02-22T00:18:16.845591Z Robin Watts</strong></p> <blockquote> <pre> -CUPS Raster output device: Fixed access to uninitialized variable, the margins array is only set when size_set is true (bug #691683). -</pre> -<p>[cups/gdevcups.c]</p> -</blockquote> +Enable mono_copy_mono implemented in terms of mono_copy_rop. -<p><strong><a name="2010-10-14T115731.187468Z"></a> -2010-10-14T11:57:31.187468Z Chris Liddell</strong></p> -<blockquote> -<pre> -Rename libtiff.mak to tiff.mak to be more consistent with the other third party libs. +Very small changes to the code to ensure that the copied area is correctly +clipped, this now gives identical results to the existing code, but should +be faster. -Bug 691681 +The tile_rectangle code is still misbehaving - will fix this in later +revisions (I hope). No cluster differences expected. </pre> -<p>[base/winlib.mak base/tiff.mak base/Makefile.in /trunk/ghostpdl/common/ugcc_top.mak base/unix-gcc.mak base/unixansi.mak base/libtiff.mak]</p> +<p>[base/gdevm1.c]</p> </blockquote> -<p><strong><a name="2010-10-13T171459.959208Z"></a> -2010-10-13T17:14:59.959208Z Robin Watts</strong></p> +<p><strong><a name="2011-02-21T171210.825257Z"></a> +2011-02-21T17:12:10.825257Z Robin Watts</strong></p> <blockquote> <pre> -Fix 2 build warnings in gdevtifs.c - -No expected differences. +Recommit of 12163 to the trunk. -</pre> -<p>[base/gdevtifs.c]</p> -</blockquote> - -<p><strong><a name="2010-10-13T160151.166726Z"></a> -2010-10-13T16:01:51.166726Z Robin Watts</strong></p> -<blockquote> -<pre> -Add new tiffscaled device. This renders internally as tiffgray, but then -downsamples by an integer scale factor (specified by -dDownScaleFactor=n) -and error diffuses to 1bpp output. +The fit_copy macro checks for the start address being off the top of the +screen, and clips it to zero. When it does this, it does: data -= y * raster, +which gives problems if raster is a uint ( as uint * int == uint in C) and +data is a 64 bit pointer. -This device is also included in pcl builds (windows ones at least), enabling -a solution for dropouts caused by rendering pcl at 200dpi. (Render at 600dpi -and scale down by a factor of 3). This should hopefully solve bug 690085. - -Future work to consider: work on bringing libtiff based devices into unix PCL -builds, consider stochastic thresholding rather than FS error diffusion. - -</pre> -<p>[base/gdevtifs.c base/openvms.mak base/gdevtifs.h base/gdevtsep.c base/configure.ac base/unix-gcc.mak doc/Devices.htm base/unixansi.mak psi/msvc32.mak base/gdevtfnx.c base/macos-mcp.mak base/devs.mak base/gdevtfax.c]</p> -</blockquote> - -<p><strong><a name="2010-10-13T104804.352147Z"></a> -2010-10-13T10:48:04.352147Z Chris Liddell</strong></p> -<blockquote> -<pre> -We have far fewer font Decodings than there are "well known" Encodings, so -assuming that for such an Encoding we always have a predefined Decoding -is problematic. - -We'll now try to find a predefined Decoding, and if one isn't found -we'll derive one from the Encoding (as we previously did only for -non-well known Encodings). - -Bug 691677 +The fix is simply to cast the result to an int before using it. This solves +various SEGVs with the mono_copy_mono using mono_copy_rop code. No cluster differences expected. </pre> -<p>[Resource/Init/gs_fntem.ps]</p> -</blockquote> - -<p><strong><a name="2010-10-12T232736.478231Z"></a> -2010-10-12T23:27:36.478231Z Robin Watts</strong></p> -<blockquote> -<pre> -Remove unused variable in siscale.c that was causing warnings. - -No expected differences. - -</pre> -<p>[base/siscale.c]</p> +<p>[base/gxdevice.h]</p> </blockquote> -<p><strong><a name="2010-10-12T162632.204667Z"></a> -2010-10-12T16:26:32.204667Z Robin Watts</strong></p> +<p><strong><a name="2011-02-21T160425.039434Z"></a> +2011-02-21T16:04:25.039434Z Chris Liddell</strong></p> <blockquote> <pre> -Update interpolation filter. When we are downscaling an image on either axis -we now use a simpler (less computationally complex) linear interpolation -filter rather than the existing mitchell filter. - -For downscaling the difference in quality between mitchell and simple -linear interpolation is not that noticable. (But the CPU/memory usage is a -quarter what it would be for proper mitchell downscaling). - -What is noticable is that the existing downscaling code is 'bent' to avoid -having to hold more than 8 temporary scaled scanlines of the image. The effect -of this is to incorrectly limit the pixels that actually go into contributing -to an output pixel, producing dropouts. - -We update the code here to remove this limit. This means that downscales -may potentially take more memory and more computation to perform, but the -overall quality is better. - -Regression tests show both noticable and unnoticable differences in files that -enable interpolation (270 or so). The noticable differences are all that the -new output looks smoother, at the expense of losing some contrast and solving -some 'jaggy' looking edges. +The structure containing the pthreads native elements making up a +gp_semaphore structure was ending up incorrectly aligned on +sparc32 Linux systems, and caused a bus error. Annoyingly, sparc32 +uses 32 bit pointers but requires 64 bit aligment. -Testing with my custom dropout test file shows a huge improvement with the -new code. I'll add this to the test repo shortly. - -</pre> -<p>[base/siscale.c]</p> -</blockquote> - -<p><strong><a name="2010-10-12T055216.851470Z"></a> -2010-10-12T05:52:16.851470Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for a large memory leak that can occur when a pattern cache entry is freed and a transparency buffer exists in the entry. A problem was that the pdf14 device, which contains pointers to the buffer, had its close device procedure set to forward due to the device being set in a disabled state during pattern_paint_finish. The close device proc for the pdf14 device contains the calls to actually free the buffers so this was not occurring (instead we were forwarding to another device). In addition, the pdf14 device itself was not being destroyed. With this commit, when the pattern entry is freed, the pdf14 device is now closed, which frees the buffers, and the pdf14 device is properly reference count decremented to result in the device itself getting freed. Regression run revealed no problems.</pre> -<p>[psi/zpcolor.c base/gxpcmap.c]</p> -</blockquote> - -<p><strong><a name="2010-10-11T075326.581165Z"></a> -2010-10-11T07:53:26.581165Z Chris Liddell</strong></p> -<blockquote> -<pre> -Update Freetype to 2.4.3 - -Revise fapi_ft.c to take into account new font(s) being added to Freetype's -"tricky" font list. "Tricky" fonts need the bytecode interpreter to produce -"correct" output. But for GS, in the case of (even "tricky") fonts which -produce an error in the bytecode interpreter, we want to try to produce -some output, even just a notdef glyph. So in the non-hinted, and notdef -fallback cases, remove the "tricky" flag from the Freetype face. +This change enforces maximum alignment for the elements of +gp_semaphore, for the current platform. No cluster differences expected. +Bug 691989 </pre> -<p>[freetype/src/pshinter/pshalgo.c psi/fapi_ft.c freetype/builds/unix/config.sub freetype/src/type42/t42parse.c freetype/builds/win32/visualce/freetype.dsp freetype/docs/reference/ft2-toc.html freetype/docs/reference/ft2-computations.html freetype/builds/unix/configure.ac freetype/builds/wince/vc2008-ce/index.html freetype/builds/unix/ftconfig.in freetype/src/sfnt/ttload.c freetype/ChangeLog.23 freetype/docs/reference/ft2-sizes_management.html freetype/src/cache/ftccache.c freetype/docs/reference/ft2-quick_advance.html freetype/include/freetype/freetype.h freetype/configure freetype/docs/reference/ft2-pfr_fonts.html freetype/docs/reference/ft2-gasp_table.html freetype/docs/reference/ft2-system_interface.html freetype/builds/unix/configure freetype/docs/reference/ft2-mac_specific.html freetype/docs/reference/ft2-basic_types.html freetype/docs/reference/ft2-lcd_filtering.html freetype/src/truetype/ttgload.c freetype/docs/reference/ft2-cid_fonts.html freetype/include/freetype/internal/ftobjs.h freetype/docs/reference/ft2-winfnt_fonts.html freetype/docs/reference/ft2-bitmap_handling.html freetype/docs/reference/ft2-cache_subsystem.html freetype/Jamfile freetype/include/freetype/ftimage.h freetype/src/base/ftobjs.c freetype/builds/win32/visualce/index.html freetype/docs/reference/ft2-glyph_variants.html freetype/docs/reference/ft2-glyph_stroker.html freetype/builds/win32/visualc/freetype.vcproj freetype/docs/reference/ft2-sfnt_names.html freetype/docs/reference/ft2-raster.html freetype/include/freetype/ftlcdfil.h freetype/builds/win32/visualce/freetype.vcproj freetype/docs/reference/ft2-bdf_fonts.html freetype/docs/reference/ft2-truetype_tables.html freetype/src/truetype/ttobjs.c freetype/builds/unix/config.guess freetype/include/freetype/config/ftconfig.h freetype/docs/reference/ft2-glyph_management.html freetype/src/autofit/aflatin.c freetype/src/raster/ftraster.c freetype/builds/win32/visualc/index.html freetype/builds/wince/vc2005-ce/index.html freetype/docs/reference/ft2-version.html freetype/docs/reference/ft2-gx_validation.html freetype/docs/reference/ft2-multiple_masters.html freetype/src/cff/cffgload.c freetype/docs/reference/ft2-base_interface.html freetype/docs/reference/ft2-header_file_macros.html freetype/builds/win32/vc2005/index.html freetype/src/cid/cidgload.c freetype/docs/reference/ft2-ot_validation.html freetype/builds/unix/unix-cc.in freetype/builds/wince/vc2005-ce/freetype.vcproj freetype/src/base/ftsynth.c freetype/src/winfonts/winfnt.c freetype/devel/ftoption.h freetype/builds/win32/vc2005/freetype.vcproj freetype/docs/reference/ft2-index.html freetype/builds/win32/vc2008/freetype.vcproj freetype/src/cache/ftcsbits.c freetype/docs/reference/ft2-outline_processing.html freetype/docs/reference/ft2-lzw.html freetype/src/truetype/ttpload.c freetype/src/smooth/ftgrays.c freetype/builds/win32/visualc/freetype.dsp freetype/src/truetype/ttinterp.c freetype/docs/reference/ft2-module_management.html freetype/src/cff/cffload.c freetype/docs/reference/ft2-user_allocation.html freetype/src/base/ftstream.c freetype/src/truetype/ttinterp.h freetype/builds/unix/configure.raw freetype/docs/reference/ft2-type1_tables.html freetype/src/sfnt/ttpost.c freetype/builds/win32/vc2008/index.html freetype/src/cff/cffobjs.c freetype/docs/reference/ft2-font_formats.html freetype/builds/wince/vc2008-ce/freetype.vcproj freetype/docs/reference/ft2-incremental.html freetype/src/smooth/ftsmooth.c freetype/ChangeLog freetype/docs/VERSION.DLL freetype/docs/reference/ft2-truetype_engine.html freetype/include/freetype/ftcache.h freetype/docs/reference/ft2-list_processing.html freetype/docs/reference/ft2-gzip.html freetype/README freetype/include/freetype/ftmodapi.h freetype/docs/CHANGES]</p> -</blockquote> - -<p><strong><a name="2010-10-10T055109.780940Z"></a> -2010-10-10T05:51:09.780940Z regression</strong></p> -<blockquote> -<pre> -Various minor fixed to the local cluster code: - - clustermonitor.pl now deals with terminal windows being resize - clustermaster.pl logs messages to clustermaster.log - build.pl now adds -dcupsColorSpace=0 to command line - run.pl now longer runs fuzzy after bmpcmp - -</pre> -<p>[toolbin/localcluster/clustermonitor.pl toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl toolbin/localcluster/compare.pl]</p> -</blockquote> - -<p><strong><a name="2010-10-08T144218.915016Z"></a> -2010-10-08T14:42:18.915016Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Process text in Tr 3 even if the Widths are non-standard - -Bug #691605 "Invisible text not preserved by pdfwrite" - -The problem was that if text in text rendering mode 4 (neither stroke nor fill) used a -font where the entries in the FontDescriptor /Widths array did not match the actual -widths in the font, the code took a path where the glyphs were not added to the 'used' -list, and so were never emitted. - -Text in regular fonts where the /Widths array was missing, or matched the widths in the -font (as the spec says they must) worked correctly. - -Fixed by processing text whose operation properties include TEXT_RENDER_MORE_3 the -same as text with the TEXT_DO_DRAW property.</pre> -<p>[base/gdevpdte.c]</p> -</blockquote> - -<p><strong><a name="2010-10-08T134241.451688Z"></a> -2010-10-08T13:42:41.451688Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove an unused variable (flagged by static analysis). -</pre> -<p>[base/gdevpsdi.c]</p> -</blockquote> - -<p><strong><a name="2010-10-08T133705.002251Z"></a> -2010-10-08T13:37:05.002251Z Ken Sharp</strong></p> -<blockquote> -<pre> -Prevent a possible attempt to memset a NULL pointer. This was probably safe since the -size of the memset would be 0 bytes, but its best to be safe. -</pre> -<p>[base/gdevpdtt.c]</p> -</blockquote> - -<p><strong><a name="2010-10-08T133400.715868Z"></a> -2010-10-08T13:34:00.715868Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove an unused variable (flagged by static analysis)</pre> -<p>[base/gdevpdfi.c]</p> +<p>[base/lib.mak base/gpsync.h]</p> </blockquote> -<p><strong><a name="2010-10-08T133111.163393Z"></a> -2010-10-08T13:31:11.163393Z Chris Liddell</strong></p> +<p><strong><a name="2011-02-21T122920.951013Z"></a> +2011-02-21T12:29:20.951013Z Robin Watts</strong></p> <blockquote> <pre> -A stringwidth operation does not always result in a call to fapi_finish_render() -which can cause Freetype glyph objects to not be freed. - -Add a firewall so we don't simply overwrite the pointer to the Freetype glyph -object, but correctly dispose of the object. - -Bug 691668 +Fix stupid typo in gsroprun.c that was causing templated rops to be different +to non templated rops. With this fixed the cluster shows identical results +(modulo indeterminisms), but the templated code is faster - so enable by +default. No cluster differences expected. </pre> -<p>[psi/fapi_ft.c]</p> -</blockquote> - -<p><strong><a name="2010-10-08T120124.908534Z"></a> -2010-10-08T12:01:24.908534Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Check encoding compatibility when finding base fonts - -Bug #691656 "crash in Chinese font: /typecheck in --.FAPIBuildGlyph--" - -A typecheck error is not a crash of course, but when using the built in font interpreter -this did not produce an error, silently discarded the text instead. This was still -incorrect. - -The problem is caused when dealing with type 0 fonts and producing multiple type 1 fonts -to handle the large number of glyphs. The code for finding an existing font (in order -to minimise the number of new fonts) or create a new font, did not consider the -encoding of an existing font when trying to match it (this did work for regular fonts). - -This could lead to a font with an incompatible encoding being used, which caused an -error later in text processing where a routine is supposed to be guaranteed no font -encoding problems. That led to an attempted fallback to the 'bitmapped type 3 font' -solution, but the text processing was passing ridiculous values to the font interpreter. - -In the old font code this caused a silent discard of the text, with the FreeType code -it produces an error. - -Fixed by checking the base font we find to see if its encoding is compatible with the -current text encoding, and manufacturing a new font if it is not. - -No differences expected. -</pre> -<p>[base/gdevpdtt.c]</p> -</blockquote> - -<p><strong><a name="2010-10-08T050927.837431Z"></a> -2010-10-08T05:09:27.837431Z Ray Johnston</strong></p> -<blockquote> -<pre> -Fix for miscalculation of clist_color_info.depth when tags are part of -the PDF14 device color. While 8 * num_components is usually enough, when -we have tags, we need the extra byte. Seen with fts_16_1601.pdf in clist -mode on HEAD and with customer 532 code when PDF14_transparency + tags is -included. -</pre> -<p>[base/gdevp14.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T135949.890609Z"></a> -2010-10-07T13:59:49.890609Z Ken Sharp</strong></p> -<blockquote> -<pre> -Put back some statements. It turns out that we can either have gcc be warning free or -the static analysis warning free. The problem is gs_note_error which uses -gs_log_error, on a release build gs_log_error is defined as the error value. - -If we don't do something with that value then gcc complains that the 'statement has no -effect'. So the code was set like this: - -ecode = gs_note_error(error code); - -But if we want to actually ignore the error and just note the problem, then we don't use -ecode and the static analysis complains that the variable is unused.... - -I'd rather have no warnings from gcc so I've restored that. -</pre> -<p>[base/gdevpdfj.c base/gdevpdfp.c base/gdevpdfu.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T124954.318945Z"></a> -2010-10-07T12:49:54.318945Z Ken Sharp</strong></p> -<blockquote> -<pre> -More changes to silence static analysis warnings. Mostly removing unused variables or -assignments. -</pre> -<p>[base/gdevpdfj.c base/gdevpdfm.c base/gdevpdfp.c base/gdevpdtb.c base/gdevpdtc.c base/gdevpdtd.c base/gdevpdtt.c base/gdevpdtf.c base/gdevpdfu.c base/gdevpdti.c base/gdevpdfi.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T083558.544234Z"></a> -2010-10-07T08:35:58.544234Z Ken Sharp</strong></p> -<blockquote> -<pre> -Silence (hopefully) some compiler warnings. -</pre> -<p>[base/gdevpdf.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T080415.270260Z"></a> -2010-10-07T08:04:15.270260Z Ken Sharp</strong></p> -<blockquote> -<pre> -Remove some unused variables and assignments flagged by static analysis.</pre> -<p>[base/gdevpdfg.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T075743.664608Z"></a> -2010-10-07T07:57:43.664608Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix a potential NULL pointer dereference flagged by static analysis. - -Other potential occurrences flagged by the analyser in this module are deemed not to be -possible, as these are picked up at a higher level. - -For instance, dereferencing a pointer to a path structure in a path handling method. We -can assume the path pointer is not NULL as we would not be called if the path was empty. -</pre> -<p>[base/gdevpdfd.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T075009.274081Z"></a> -2010-10-07T07:50:09.274081Z Ken Sharp</strong></p> -<blockquote> -<pre> -Static analysis discovered two variables being altered that are not subsequently used. -Although this is safe, removed the code anyway. -</pre> -<p>[base/gdevpdfb.c]</p> -</blockquote> - -<p><strong><a name="2010-10-07T074913.279339Z"></a> -2010-10-07T07:49:13.279339Z Ken Sharp</strong></p> -<blockquote> -<pre> -static analysis found that the result of fread was not being used. Add code to test the -result and flag a warning if expected data not read.</pre> -<p>[base/gdevpdf.c]</p> -</blockquote> - -<p><strong><a name="2010-10-06T140332.653153Z"></a> -2010-10-06T14:03:32.653153Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix for part 2 of Bug 691484, valgrind warnings about uninitialised values -in clist code. - -The problem is that we are writing out a cmd_block without initialising it all. -The fix is simply to initialise it (using a memset, so accounting for all -padding bytes too) before starting to use it. - -This stops the valgrind warnings. No changes in localcluster testing. - - -</pre> -<p>[base/gxclist.c]</p> -</blockquote> - -<p><strong><a name="2010-10-06T134815.425458Z"></a> -2010-10-06T13:48:15.425458Z Ken Sharp</strong></p> -<blockquote> -<pre> -Add some body parentheses to 'if' statements in order to silence some clang warnings. -</pre> -<p>[base/gdevpdfp.c base/gdevpdtf.c]</p> -</blockquote> - -<p><strong><a name="2010-10-06T120646.017717Z"></a> -2010-10-06T12:06:46.017717Z Robin Watts</strong></p> -<blockquote> -<pre> -Whitespace tweaks to gxiscale.c. The complexity in the file is more than -enough for my tiny brain without expecting it to cope with inconsistent -indentation too :) - -</pre> -<p>[base/gxiscale.c]</p> -</blockquote> - -<p><strong><a name="2010-10-05T213811.272406Z"></a> -2010-10-05T21:38:11.272406Z Robin Watts</strong></p> -<blockquote> -<pre> -Fix for part 1 of bug 691484 - uninitialised memory usage in clist code. - -The FAPI code copies bitmaps and pads them out so that each raster line -is appropriately aligned. Previously the padding bytes were left -uninitialised. Unfortunately the clist code reads the padding when -compressing the bitmaps, which a) upsets valgrind and b) means that the -exact size of the clist will vary from run to run. - -Here we tweak the copying code to ensure that the padding bytes are always -set to zero. - -No differences shown in local cluster. This solves part 1 of the bug. - - -</pre> -<p>[psi/zfapi.c]</p> -</blockquote> - -<p><strong><a name="2010-10-05T202754.714250Z"></a> -2010-10-05T20:27:54.714250Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Clean up of a few comments about device profiles</pre> -<p>[base/gsicc_manage.c]</p> -</blockquote> - -<p><strong><a name="2010-10-05T201810.046358Z"></a> -2010-10-05T20:18:10.046358Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix for error in detecting the presence of a device profile set in the command line. Unfortunately, the device was not being reset from the default profile based upon the setting.</pre> -<p>[base/gsicc_manage.c]</p> -</blockquote> - -<p><strong><a name="2010-10-05T135722.688207Z"></a> -2010-10-05T13:57:22.688207Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Add missing decoding of #nn escape to encrypted PDF reader. Besides fixing the -bug sample file, this patch also corrects a colorant name in IA3Z0440.pdf on -psdcmyk device. Bug 691636. -</pre> -<p>[Resource/Init/pdf_sec.ps]</p> -</blockquote> - -<p><strong><a name="2010-10-05T124816.473671Z"></a> -2010-10-05T12:48:16.473671Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : ConvertCMYKImagesToRGB not working - -Bug #691647 "-dConvertCMYKImagesToRGB no longer works" - -Originally caused by the conversion to the ICC workflow, which meant that all images -appear to be in a ICC space, and only images originally natively CMYK are converted. - -Probing the ICC space using the provided utility to return the original colour space -allows the code to work, but reveals a more serious error. The code in -psdf_setup_image_filteres() alters the image colour space and decrements the reference -count of the original colour space. - -This seems logically correct, and in one of the three calling paths it is correct, but -under one of the other two conditions it causes a crash. The routine -pdf_begin_typed_image_impl() makes two copies of the original image parameters, and -when it does so it does *not* increment the reference counts of any counted objects. -This copied data is presented to the image filter setup several times, and if CMUK -to RGB conversion is going on the original colour space is decremented each time. This -leads to obvious problems. - -The simplest solution would be to increment the reference counts when the copy is made, -but that would mean checking all the error condition break outs, and decrementing the -reference count in each case. - -Since the colour space is only decremented in the filter setup, this patch increments -the count before the call, and if the colour space is the same afterwards (whether -an error occurred or not) decrements it back again. If the colour space changes we do -not decrement the space of course, as the filter setup routine has done that. - -In addition, extended the test for whether CMYK images should be converted to include -the original test of the native space, in case we get here after an image has been -converted to a base space and no longer has an ICC space. - -No expected differences, this configuration is not tested by the regression suite. -</pre> -<p>[base/gdevpsdi.c base/gdevpdfi.c]</p> +<p>[base/gsroprun.c]</p> </blockquote> -<p><strong><a name="2010-10-05T121046.672154Z"></a> -2010-10-05T12:10:46.672154Z Robin Watts</strong></p> +<p><strong><a name="2011-02-20T124120.382249Z"></a> +2011-02-20T12:41:20.382249Z Robin Watts</strong></p> <blockquote> <pre> -Fix for part 1 of Bug 691635, supplied by Norbert Janssen. Many thanks. +Initial reorganisation of code towards using copy_rops for copy_mono. -In the recent work to remove global variables where possible, I had failed to -change an instance of iodev_default to be iodev_default(mem). +Split the guts of mem_mono_strip_copy_rop out into a separate function +mem_mem_strip_copy_rop_dev. This new function handles the actual copy in +device space, leaving the original to cope with fiddling the rop according +to colors. -No expected changes. +This 'inner' function is moved to gdevm1.c so it is present in both gs +and ghostpcl builds. The existing (bitrotted) code in gdevm1.c to +'USE_COPY_ROP' is revamped to call mem_strip_copy_rop_dev, but is disabled +currently as the cluster is showing a few differences that need to be +tracked down. -</pre> -<p>[base/gsiodisk.c]</p> -</blockquote> +Also, this introduces new code to do gsroprun's using code in a generic +header file that gets repeatedly #included with different options. This +code is currently disabled until we can verify that it gives identical +results. The new 'templated' code uses native ints where possible, and +(in initial limited testing) seems to perform better than copy_mono. -<p><strong><a name="2010-10-03T161300.326561Z"></a> -2010-10-03T16:13:00.326561Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Change the order of operands in a logical expression to avoid dereferencing -an uninitialized variable. Bug 690214. -</pre> -<p>[psi/zfont2.c]</p> -</blockquote> +No cluster differences expected. -<p><strong><a name="2010-10-01T193606.952768Z"></a> -2010-10-01T19:36:06.952768Z Ray Johnston</strong></p> -<blockquote> -<pre> -Drop support for these less popular compilers. This will be the first step to -changing to project files for Windows. </pre> -<p>[base/wctail.mak base/watclib.mak base/bcwin32.mak base/gp_iwatc.c base/watcw32.mak base/wccommon.mak]</p> -</blockquote> - -<p><strong><a name="2010-10-01T025815.408387Z"></a> -2010-10-01T02:58:15.408387Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Replace sequential CFF parser coded in PostScript with a parser that uses -direct access to the data and coded in C. Solve numerous problems caused by -the old parser. New -dOLDCFF option can revert to the old parser. Differences -in 16-01.PS.pdf and 16-01.PS.pdf are progressions. - </pre> -<p>[doc/Use.htm psi/int.mak psi/zfont1.c psi/zfont2.c Resource/Init/gs_cff.ps]</p> +<p>[base/gdevmem.h base/lib.mak base/gsroprun.c base/gdevm1.c base/gsropt.h base/gsroprun1.h base/gdevmr1.c]</p> </blockquote> -<p><strong><a name="2010-09-29T155022.840688Z"></a> -2010-09-29T15:50:22.840688Z Ray Johnston</strong></p> +<p><strong><a name="2011-02-19T070113.923016Z"></a> +2011-02-19T07:01:13.923016Z Alex Cherepanov</strong></p> <blockquote> <pre> -Fix calculation of offset to tag plane in pdf14_mark_fill_rectangle to cure -writing past the end of an allocated buffer. Detected with customer 532 on -fts_08_0808.pdf. Only affects devices with object tagging (bitrgbtags). +Add a missing check for null value during PDF resource enumeration. +Bug 691892, customer 532. </pre> -<p>[base/gdevp14.c]</p> +<p>[Resource/Init/pdf_main.ps]</p> </blockquote> -<p><strong><a name="2010-09-28T123641.051799Z"></a> -2010-09-28T12:36:41.051799Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-18T132259.764503Z"></a> +2011-02-18T13:22:59.764503Z Robin Watts</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Don't unreasonably limit the PDF output level +Committing fix for Bug 689031 submitted by Shailesh Mistry under the +bug bounty program. Tests out fine (1 minor difference, looks like a +progression to me). -Bug #691318 " -dCompatibilityLevel=1.6 produces PDF 1.5" +See bug for full discussion, but basically this removes a few calls to +path_position_valid in exchange for accessing the equivalent data kept +locally. -Although the highest output level for pdfwrite features is 1.5, it is possible to use -pdfmarks to create a PDF file which uses higher level features. In this case its -reasonable to have pdfwrite produce a higher level PDF file. -This patch allows pdfwrite to produce output up to PDF 1.7, the highest currently -specified. - -No differences expected. </pre> -<p>[base/gdevpdfp.c]</p> +<p>[base/gxchar.c base/gzpath.h base/gxccache.c base/gspath1.c]</p> </blockquote> -<p><strong><a name="2010-09-28T122613.182021Z"></a> -2010-09-28T12:26:13.182021Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-18T115125.345393Z"></a> +2011-02-18T11:51:25.345393Z Ken Sharp</strong></p> <blockquote> <pre> -Fix (pdfwrite) : allow for UserPasword and OwnerPassword in page device - -Bug #691256 "OwnerPassword and UserPassword don't work as device parameters" +Enhancement (pdfwrite) : performance improvement -pdfwrite sets up encryption filters when the device is opened, and the device is not -(currently) closed until Ghostscript shuts down. This means that changes to the page -device dictionary which require a restart (eg the encryption parameters) do not affect -the current setup, though they may be (incorrectly) written when the device is closed. +Bug #691946 "Conversion to PDF becomes slower and slower" -This patch addresses the specific issue of OwnerPassword by closing the device if the -password is changed *and* we have not yet written any pages. If we have already begun -the output when a password change occurs then we ignore it and flag a warning. +There are many places where pdfwrite compares composite objects for equality. This can +be a very slow process, depending on the nature of the object, and becomes progressively +slower as more object are added to storage. -This is also a first step in the direction of making pdfwrite open and close properly -so that we don't need to restart Ghostscript to use it. +Previously we had added a MD5 hash to the stream data of a cos_stream in order to +improve the performance when checking fonts for equality, this change takes the whole +process much further. We now store an MD5 'fingerprint' for each composite object, +initially this is not computed and is marked as not valid. -No expected differences. -</pre> -<p>[base/gdevpdfp.c]</p> -</blockquote> +Whenever an equality test takes place we check to see if the composite object has an MD5 +hash calculated, and if it does, we compare the MD5 hashes. If it does not then we +compute an MD5 hash, store it, and mark it as valid. Note that for cos_stream types +we store *two* hashes, one for the dictionary and one for the stream data. -<p><strong><a name="2010-09-27T120517.449032Z"></a> -2010-09-27T12:05:17.449032Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (Fonts): Prevent xfont being used in composefont +If we alter the contents of a composite object then we mark its MD5 hash as invalid so +that we recompute it on the next occurence. Technically there could be a problem if +a composite object contains a composite object, and the descendant object is altered +after the MD5 hash is calculated for the parent. However this should not occur given +the way these structures are used (these are pdfwrite internal structures, *not* PS or +PDF objects available to the interpreter). -On platforms supporting X-Windows xfonts can be used with Ghostscript, however we don't -want to find an xfont (eg Courier) when using composefont to create a CID-Keyed instance -as this will not work. +This very significantly improves performance on some files, the test file for bug +#691946 takes 2642 seconds without this change (and DetectDuplicateImages true) while +it takes 963 seconds after this change. -Test to see if the top level font is a type 0, and if it is, don't search for a matching -xfont, but instead go through the usual PostScript machinery. +Note that this change depends on revision 12169 and should ideally be used with +revisions 12168 to 12171 inclusive. -No differences expected. +No other differences expected. </pre> -<p>[base/gxchar.c]</p> +<p>[base/gdevpdfo.c base/gdevpdfo.h]</p> </blockquote> -<p><strong><a name="2010-09-27T093355.410495Z"></a> -2010-09-27T09:33:55.410495Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-18T113756.561896Z"></a> +2011-02-18T11:37:56.561896Z Ken Sharp</strong></p> <blockquote> <pre> -Fix (pdfwrite/ps2write) : Don't dereference mask colour spaces +Fix (pdfwrite) : images being scaled incorrectly -Bug #691106 "-sDEVICE=pdfwrite -dConvertCMYKImagesToRGB=true" +Found while dealing with other problems. pdfwrite uses the image 'height' (rendered +height) and number of lines of data to calculate a 'scale' which it then applies to +the current Transformation Matrix in order to calculate an image matrix. -When checking to see if an image needs to be converted to RGB, the image space is -checked to see if it is CMYK. However an image mask does not have a colour space (it -is NULL), firstly so that we can tell its an image mask, and secondly because masks -genuinely do not have a colour space, they take on the current colour. +However, when an image was detected as a duplicate, the scale factor was calculated +from the first image's dimensions, and then applied to the CTM for the second matrix. -Attempting to dereference the NULL colour space causes a crash. Since a mask never -needs converting to RGB, we short circuit the test by detecting a NULL colour space. +This did not appear to cause problems for PostScript and PDF but causes serious bugs +in a number of PCL files, and was clearly incorrect. We now save and restore the +height and width when substituting images to prevent this problem </pre> -<p>[base/gdevpsdi.c]</p> +<p>[base/gdevpdfj.c]</p> </blockquote> -<p><strong><a name="2010-09-25T020822.451780Z"></a> -2010-09-25T02:08:22.451780Z Alex Cherepanov</strong></p> +<p><strong><a name="2011-02-18T113207.033929Z"></a> +2011-02-18T11:32:07.033929Z Ken Sharp</strong></p> <blockquote> <pre> -For long time ps2pdf*.bat files failed when they were used with some -options and a single argument. findstr is now used to identify -options by the leading '-' and handle this case. Bug 691622. -</pre> -<p>[lib/ps2pdf.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat]</p> -</blockquote> +enhancement (pdfwrite) : Allow duplication image detection to be disabled -<p><strong><a name="2010-09-24T132507.243032Z"></a> -2010-09-24T13:25:07.243032Z Chris Liddell</strong></p> -<blockquote> -<pre> -For disk based TTFs, only lookup the character code in the TTF cmap if the font is -not using an Identity ordering. +pdfwrite tests every (non-inline) image against every other stored image to see if it is +a duplicate, and if so does not embed the duplicate in the output but simply references +the original. -No cluster differences expected. +This can be slow for files with many images (each stored image must be checked when a +new image is encountered) and may be of limited benefit. -Bug 691623. +The new flag DetectDuplicateImages (default true) can be used to enable or disable +this behaviour +No differences expected </pre> -<p>[psi/zfapi.c]</p> +<p>[base/gdevpdfj.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]</p> </blockquote> -<p><strong><a name="2010-09-24T090334.206583Z"></a> -2010-09-24T09:03:34.206583Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-18T112524.853829Z"></a> +2011-02-18T11:25:24.853829Z Ken Sharp</strong></p> <blockquote> <pre> -Fix (TrueType fonts) : memory leak - -Bug #691088 This does not affect the PostScript/PDF interpreters which now use FreeType -but is relevant still for XPS and PCL. - -A buffer was allocated to contain the GSUB table from the TT font, but was never freed -leading to memory leaks. I've adopted the same approach as that taken for the 'glyph -length' array and added a notification procedure which is called when the font is -released, and that procedure frees the GSUB buffer. +Fix (pdfwrite) : Correction to an equality test -At the same time, removed the functions: -add_quadratic_curve -append_simple -check_component +This fixes a long-standing bug when checking the equality of patterns. -These were only called by each other, or by append_component which had already been -removed as unused. +We need to ensure when substituting patterns that neither of the patterns is already +substituted. But the code only tested one of the patterns (and was a duplicate of +another test), which led to incorrect results. This should always have been a problem +but for some reason seems to have been masked in previous releases. New code for +testing equality of composite objects revealed the problem. -No expected differences. +No differences expected, as the problem is only revealed with code which follows in a +subsequent commit. </pre> -<p>[base/gstype42.c]</p> -</blockquote> - -<p><strong><a name="2010-09-24T032745.689228Z"></a> -2010-09-24T03:27:45.689228Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Removal of debug code that was accidentally committed.</pre> -<p>[base/gdevp14.c]</p> -</blockquote> - -<p><strong><a name="2010-09-23T194527.249371Z"></a> -2010-09-23T19:45:27.249371Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Fix so that objects tag information makes it through transparency rendering AND the clist. An issue was that the pdf14 encode and decode procedures are used as opposed to the target device encode and decode procedures and it is through a value in the color index that we currently communicate the object type through the clist. When we are in page rendering mode, it is easy to get the current object from mem->gs_lib_ctx->BITTAG, but this is not set correctly in clist rendering if for example a glyph is stored in the clist as a mask fill. Instead the information about the object is extracted from the color index. So, to make this work, we had to introduce an encode method for the pdf14 device that incorporates the tag information and also make sure that the bit depth for the pdf14 color info value is incremented appropriately so that the extra byte is stored and extracted from the clist. The object type is then recovered during the pdf14 mark fill rect procedure. This was tested with the updated bitrgbtags device using a custom file that has overlapping text, image and path objects with varying transparency amounts. </pre> -<p>[base/gdevp14.c base/gsimage.c base/gsutil.h base/gstext.c base/gsdps1.c base/gdevbit.c base/gdevmem.c base/gxblend1.c base/gspaint.c base/gdevddrw.c base/gsutil.c base/gxclrast.c base/gxblend.h]</p> +<p>[base/gdevpdfi.c]</p> </blockquote> -<p><strong><a name="2010-09-23T144650.766627Z"></a> -2010-09-23T14:46:50.766627Z Robin Watts</strong></p> +<p><strong><a name="2011-02-18T111523.457563Z"></a> +2011-02-18T11:15:23.457563Z Ken Sharp</strong></p> <blockquote> <pre> -Final part of the fix for bug 691612. - -Currently the code blindly sets the "lop_pdf14" whenever the pdf14 device is -in use. This forces the 'lop_is_idempotent' test to fail, which in turn forces -slower cases to be taken through the code. - -This patch alters that logic, so that the pdf14 device can leave that bit -unset if the parameters are set up in such a way that the lop really can -be idempotent (i.e. normal blending, solid alphas etc). - -This vastly improves the speed of rendering non-alpha content, so we are no -longer penalised for having just a small amount of transparent content on a -page. - -Testing shows 398 files that change, but bmpcmp reveals these all to be very -small changes to do with whether individual pixels are filled or not. This -is consistent with the typical mismatches between special case and normal -renderings, so can safely be ignored for now. - - +Fix a typo in an enumerated type. No differences expected. </pre> -<p>[base/gdevp14.c]</p> +<p>[base/gxhldevc.h base/gxhldevc.c base/gdevpdfg.c]</p> </blockquote> -<p><strong><a name="2010-09-23T121757.296649Z"></a> -2010-09-23T12:17:57.296649Z Robin Watts</strong></p> +<p><strong><a name="2011-02-15T163659.934186Z"></a> +2011-02-15T16:36:59.934186Z Henry Stiles</strong></p> <blockquote> <pre> -As part of the investigation into bug 691612, we noticed that the clist -band playback code doesn't call the device stroke_path method, but instead -calls the default implementation directly. - -In order the fix the bug, we'd like it to call through the device version -(pdf14_stroke_path). Consensus is that it's an oversight that it's not calling -the device version already, and tests indicate no differences (*) so this -patch changes it to call via the vector. - -(* Actually regression testing shows 2 pdfwrite differences, but they are -in unbanded tests, so can't be executing this code, so are probably just -indeterminisms). - +Double the allowed space for cached chars and increase the maximum +byte size of a single glyph that can be cached. </pre> -<p>[base/gxclrast.c]</p> +<p>[base/gsfont.c]</p> </blockquote> -<p><strong><a name="2010-09-23T104633.821569Z"></a> -2010-09-23T10:46:33.821569Z Robin Watts</strong></p> +<p><strong><a name="2011-02-15T150755.282721Z"></a> +2011-02-15T15:07:55.282721Z Ray Johnston</strong></p> <blockquote> <pre> -As part of the investigation into bug 691612, a problem was found with the -rop3_is_idempotent (and hence lop_is_idempotent) macros. This patch fixes -this definition and adds some more comments explaining the rop operations. - -Thanks to lpd for confirming this change. - -This produces 78 differences in the regression tests, bmpcmp reveals these to -all be neutral or progressions (in some cases, significant progressions). - - +Fix for building the gs***w64.exe self extracting installer compatible with +the new 64-bit binary naming and makefile macro (BUILD_SYSTEM) </pre> -<p>[base/gsropt.h]</p> +<p>[psi/winint.mak]</p> </blockquote> -<p><strong><a name="2010-09-23T081636.207911Z"></a> -2010-09-23T08:16:36.207911Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-15T092128.927211Z"></a> +2011-02-15T09:21:28.927211Z Chris Liddell</strong></p> <blockquote> <pre> -Fix (pdfwrite) : Do not write Encodings with Symbolic TrueType fonts - -Bug #690744, #691036, #691319. The PDF specification makes it clear that Symbolic -TrueType fonts should not have a FontDescriptor which contains an Encoding entry. -pdfwrite has specifically been doing this, the reason being (code comments) : - - * We write True Types with Symbolic flag set. - * PDF spec says that "symbolic font should not specify Encoding entry" - * (see section 5.5, the article "Encodings for True Type fonts", paragraph 3). - * However Acrobat Reader 4,5,6 fail when TT font with no Encoding - * appears in a document together with a CID font with a non-standard CMap - * (AR 4 and 5 claim "The encoding (CMap) specified by a font is corrupted." - * (we read it as "The encoding or CMap specified by a font is corrupted.", - * and apply the 1st alternative)). We believe that AR is buggy, - * and therefore we write an Encoding with non-CID True Type fonts. - * Hopely other viewers can ignore Encoding in such case. Actually in this case - * an Encoding doesn't add an useful information. +Ensure that the OpenPrinting drivers get removed from the drivers list +if iconv/libiconv are not available. -Since this is working around a bug in old versions of Acrobat, and the presence of an -Encoding causes preflight errors and is specifically forbidden in PDF/A, this work -around has been removed. I would like to check recent versions of Acrobat to see if -this issue persists, but am unable to find an example file. The change predates the -adoption of Subversion, the first logged change is October 2003. +The strings used to identify the drivers in the list were incorrect. </pre> -<p>[base/gdevpdtt.c]</p> +<p>[base/configure.ac]</p> </blockquote> -<p><strong><a name="2010-09-22T151320.906048Z"></a> -2010-09-22T15:13:20.906048Z Marcos H. Woehrmann</strong></p> +<p><strong><a name="2011-02-14T203933.924424Z"></a> +2011-02-14T20:39:33.924424Z Robin Watts</strong></p> <blockquote> <pre> -Removed unused label from base/gxicolor.c that caused compiler warning. - -Fixes Bug #691633 reported by Norbert Janssen. - -</pre> -<p>[base/gxicolor.c]</p> -</blockquote> +Fix Bug 691917. In revision 11146 I made op_array_table_global and +op_array_table_local be elements of the context rather than being +globals, and changed all the code to access these elements through +the context. -<p><strong><a name="2010-09-21T120352.655546Z"></a> -2010-09-21T12:03:52.655546Z Chris Liddell</strong></p> -<blockquote> -<pre> -Add the new entries for produce outlines and maximum bitmap size -to the FAPI server declarations in the UFST and Bitstream code. +Unfortunately I forgot to cope with when new contexts are generated by +forking execution. The correct fix is, I believe to simply copy the +op_table pointers over to the new context. This has been done here, and +seems to solve the reported bug. No cluster differences expected. -Bug 691634 - -</pre> -<p>[psi/fapiufst.c psi/fapibstm.c]</p> -</blockquote> - -<p><strong><a name="2010-09-20T012614.070109Z"></a> -2010-09-20T01:26:14.070109Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Fix end-of-file detection in reusable streams. Don't try to read non-existing -blocks after the last one. Just return EOF flag and the data that are already -in the buffer. Bug 691625. -</pre> -<p>[psi/zfrsd.c]</p> -</blockquote> - -<p><strong><a name="2010-09-17T102936.728794Z"></a> -2010-09-17T10:29:36.728794Z Robin Watts</strong></p> -<blockquote> -<pre> -In revision 11723 I'd copied a prototype, but forgotten to edit the name. -(bytes_copy_rectangle to bytes_copy_rectangle_zero_padding). -This was resulting in a couple of warnings about 'no previous prototype'. - -No expected differences. - </pre> -<p>[base/gsbitops.h]</p> +<p>[psi/zcontext.c]</p> </blockquote> -<p><strong><a name="2010-09-17T064427.206613Z"></a> -2010-09-17T06:44:27.206613Z Michael Vrhel</strong></p> +<p><strong><a name="2011-02-14T110439.509187Z"></a> +2011-02-14T11:04:39.509187Z Till Kamppeter</strong></p> <blockquote> <pre> -Removal of unused variable introduced in last commit.</pre> -<p>[base/gdevp14.c]</p> -</blockquote> - -<p><strong><a name="2010-09-17T054048.428712Z"></a> -2010-09-17T05:40:48.428712Z Michael Vrhel</strong></p> -<blockquote> -<pre> -Addition of support to enable persistence of objects tag information through transparency rendering. In the current code base, transparency blending erases all knowledge about the objects that were drawn and blended, setting the entire object to image type. With this commit, the tag information is retained through blending by doing a bit-wise or of the tag values. When a device supports tags, the pdf14 device will create an additional plane to maintain the tag data information. Blending of the tag information occurs in pdf14_mark_fill_rectangle, pdf14_mark_fill_rectangle_ko_simple and pdf14_compose_group. A new device procedure called put_image is added. This is called by the pdf14_put_image operation, which enables the communication of the tag information to the target device. pdf14_put_image will first attempt to pass the alpha channel and the image data not scaled by the alpha channel and the tag data to the target device. The planar offset location of the alpha and tag data is communicated in the put_image procedure interface. If the target device cannot handle this form of the data, it should return 0. The pdf14_put_image operation will then blend the alpha data and attempt the put_image again but this time with an alpha offset of 0 to indicate that there is no alpha data. Note that the alpha data remains valid for those devices that still want the alpha but also want to have the graphics library do a premultiplcation of the alpha with the data. Details of this interface will be added to the documentation. In addition, the bitrgbtags device is being updated to demonstrate the use of the put_image procedure.</pre> -<p>[base/gdevp14.c base/gxdevcli.h base/gxclist.c base/gdevp14.h base/gdevbbox.c cups/gdevcups.c base/gsovrc.c base/gxblend.c base/gxblend1.c base/gdevprn.c base/gsutil.c base/gxblend.h]</p> -</blockquote> - -<p><strong><a name="2010-09-16T145706.777148Z"></a> -2010-09-16T14:57:06.777148Z Alex Cherepanov</strong></p> -<blockquote> -<pre> -Fix a problem introduced by the rev. 11497 that broke ps2pdf*.bat scripts -when they receive optional arguments. The bug results from interaction between -"shift" and %~dp0 that is used after the "shift". +Removed a tab accidentally introduced in rev 12082. </pre> -<p>[lib/ps2pdf.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat]</p> +<p>[Resource/Init/cidfmap]</p> </blockquote> -<p><strong><a name="2010-09-16T110931.082242Z"></a> -2010-09-16T11:09:31.082242Z Robin Watts</strong></p> +<p><strong><a name="2011-02-10T171423.128533Z"></a> +2011-02-10T17:14:23.128533Z Chris Liddell</strong></p> <blockquote> <pre> -Another partial fix for Bug 690993. The sole remaining Valgrind warning -is that memcpy is called on overlapping src/dst blocks in cmd_read_data. - -Investigation supports this, and suggests that we should be using memmove -instead. This does stop the error, and leaves us valgrind warning free. - -This also appears to resolve the indeterminism, in that repeated runs -of the command line given in the bug return identical results. - -The bug remains open though, as there is still a mismatch between banded and -non-banded mode. - -No expected differences. +Ensure that a --build option is propogated to the other +configure scripts we call. </pre> -<p>[base/gxclrast.c]</p> +<p>[base/configure.ac]</p> </blockquote> -<p><strong><a name="2010-09-16T110547.689000Z"></a> -2010-09-16T11:05:47.689000Z Robin Watts</strong></p> +<p><strong><a name="2011-02-10T132158.493309Z"></a> +2011-02-10T13:21:58.493309Z Ken Sharp</strong></p> <blockquote> <pre> -Partial 'fix' for Bug 690993. When encoding a bitmap into a clist, we -copy it into a block with potentially larger padding requirements. These -extra padding bytes were left undefined, causing subsequent attempts to -compress the bitmap to cause valgrind to give warnings. - -The fix is simply to introduce and use a new function that copies a bitmap -and zeros the padding. This should eliminate the warnings, produce better -compression, and (more importantly) mean that every run uses the same amount -of memory, hence eliminating potential odd effects where clists may be of -different lengths on different runs. +fix error in revision 12140 -This still leaves bug 690993 open. - -No expected differences. +When fetching the size of the stream for a /Indexed colour space, omitted to check if the +/Length of the stream was an indirect object. Now dereference the object if this is the +case. +Should fix the 14 files with errors introduced in 12140. </pre> -<p>[base/gsbitops.c base/gsbitops.h base/gxclbits.c]</p> +<p>[Resource/Init/pdf_draw.ps]</p> </blockquote> -<p><strong><a name="2010-09-15T081552.075230Z"></a> -2010-09-15T08:15:52.075230Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-10T104326.255155Z"></a> +2011-02-10T10:43:26.255155Z Ken Sharp</strong></p> <blockquote> <pre> -Fix (ps2write) : Bug #689419 "Text missing if nested BT with opdfread.ps" - -Type 3 fonts which select another font and then draw text from it (a common feature of -Quark Xpress) can result in nested 'BT' operators when processed by ps2write. +Fix : colour space handling bug and improved handling of broken ICC space -The opdfread prologue does not cater for this, specifically the TextMatrix is not saved -and restored around a BT/ET pair. If the text matrix is altered by the font -selection, then the 'ET' will not restore the old matrix leading to incorrectly sized or -disappearing text. +Bug #691941 "Interpretation of PDF aborts with /typecheck" -The patch (supplied by SaGS) saves the TextMatrix in a stack (stored in an array) and -restores the matrix after an ET, in case it is nested. Currently this allows for -nesting up to 20 deep, which should be more than adequate. Note that if we were to -encounter a nested BT with no ET this would still fail, but in this case the file -produced by ps2write would be invalid, and the missing ET should be fixed. +The PDF file in the specimen contains an invalid colour space of the form: -No differences expected, the regression suite doesn't test ps2write. -</pre> -<p>[Resource/Init/opdfread.ps]</p> -</blockquote> +/Indexed [/ICCBased <</N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]>>] 255 7 0 R] -<p><strong><a name="2010-09-14T125809.089527Z"></a> -2010-09-14T12:58:09.089527Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix (pdfwrite) : Don't colour convert SMask images +The number of components in the ICCBased specification is incorrect, as the profile has +3 channels. This was not detected previously. Falling back to the /Alternate we see +that we have a /Indexed space depending on a /Indexed space which is also invalid, but +we choose to ignore this. -Bug #690612 "PDF sRGB conversion loses images" +There was also a bug in the colour space handling for ICCbased spaces which caused a +typecheck if the alternate space was a /Indexed space. -The handling of SMask images in pdfwrite is a bit convoluted. These are handled by -converting initially to a DevicePixel colour space, then detecting that later and -replacing with a DeviceGray space. However, after doing so, if ColorConversionStrategy -was set, the space (and image samples) would be converted to another colour space. This -is not legal for SMask images. +Finally, the PDF interpreter is updated so that when given a stream as the data source +for a /Indexed space it reads and returns a string which is the greater of the declared +size of the stream, or the calculated size required, given the number of components. +Previously we always returned the calculated size, which was too little in this case +as the number of components in the ICCBased space is incorrect. -This code simply checks to see if the image is an SMask before setting colour conversion -and doesn't convert the colour space/samples if it is and SMask. +With these changes the (invalid) specimen file runs to completion. -No expected differences. +No differences expected. </pre> -<p>[base/gdevpdfi.c]</p> -</blockquote> - -<p><strong><a name="2010-09-14T090706.998296Z"></a> -2010-09-14T09:07:06.998296Z Ken Sharp</strong></p> -<blockquote> -<pre> -Fix a compiler warning.</pre> -<p>[base/gdevpdfo.c]</p> +<p>[psi/zcolor.c psi/zicc.c Resource/Init/pdf_draw.ps]</p> </blockquote> -<p><strong><a name="2010-09-14T080603.949247Z"></a> -2010-09-14T08:06:03.949247Z Ken Sharp</strong></p> +<p><strong><a name="2011-02-10T103323.506445Z"></a> +2011-02-10T10:33:23.506445Z Ken Sharp</strong></p> <blockquote> <pre> -pdfwrite enhancement : performance improvement with type 3 fonts - -Bug #690575 "PS to PDF Conversion extremely slow (possibly endless)" +Fix Bug #691918 -The type 3 font code assembles CharProcs for type 3 fonts by writing them individually -into a 'cos_stream'. Each time a new one is completed it is compared to all the existing -CharProcs to see if it is a duplicate. This was done by fseek/fread/memcmp operations. +Update the Unicode decodings applied to TrueType fonts to match the latest Adobe glyph +list. Fixes some problems with incorrect mappings and adds numerous new mappings. A +similar but less extensive change is made to the FCO_Unicode mappings as well. -As the number of CharProcs increases, the time spent seeking, reading and comparing -the data increases dramatically and performance becomes very poor. Not only that, but -the test is actually done twice for each new CharProc. +Thanks to SaGS for the work on this problem. -This patch tackles the problem by creating an md5 hash of the data written to a -cos_write_stream (a subclassed cos_stream) as it is written. The cos_stream 'equal' -routine checks to see if the md5 hash is valid and if it is then compares the hashes. -If the md5 hash is not valid (ie not a cos_write_stream) then it uses the old -seek/read/compare mechanism. This will improve the performance of any stored data -if it is stored using a cos_write_stream and compared against other data of the same -type. (I don't believe we do this anywhere else currently, but I'm not suer) - -This does improve the performance significantly, and the code no longer spends most of -its time waiting for I/O operations to complete. It is still slow, but this is the -result of using lots of type 3 fonts. Because of the way these must be processed in -order to capture the outlines they are never going to be fast. - -In my test this runs 2-3 times faster than before. There should be no differences in -output from the old code. -</pre> -<p>[base/gdevpdfo.c base/gdevpdfo.h]</p> -</blockquote> - -<p><strong><a name="2010-09-14T074911.816447Z"></a> -2010-09-14T07:49:11.816447Z Chris Liddell</strong></p> -<blockquote> -<pre> -Bump version number to 9.01 and associated changes. - -</pre> -<p>[base/gscdef.c base/version.mak Resource/Init/gs_init.ps]</p> +No differences expected as these are only used for ToUnicode CMaps.</pre> +<p>[Resource/Decoding/Unicode Resource/Decoding/FCO_Unicode]</p> </blockquote> </body> </html> diff --git a/gs/doc/Details8.htm b/gs/doc/Details8.htm index 550eab023..f648d8bfd 100644 --- a/gs/doc/Details8.htm +++ b/gs/doc/Details8.htm @@ -104190,7 +104190,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Details9.htm b/gs/doc/Details9.htm index 02ff0d8de..528bc587c 100644 --- a/gs/doc/Details9.htm +++ b/gs/doc/Details9.htm @@ -13041,7 +13041,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Develop.htm b/gs/doc/Develop.htm index ff7e4745a..6c89312b0 100644 --- a/gs/doc/Develop.htm +++ b/gs/doc/Develop.htm @@ -4870,7 +4870,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Devices.htm b/gs/doc/Devices.htm index 2e3fc262e..b46341209 100644 --- a/gs/doc/Devices.htm +++ b/gs/doc/Devices.htm @@ -1679,7 +1679,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Drivers.htm b/gs/doc/Drivers.htm index 7eb146372..32d1c82ac 100644 --- a/gs/doc/Drivers.htm +++ b/gs/doc/Drivers.htm @@ -3319,7 +3319,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Fonts.htm b/gs/doc/Fonts.htm index b1f239109..13eafe56d 100644 --- a/gs/doc/Fonts.htm +++ b/gs/doc/Fonts.htm @@ -774,7 +774,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Helpers.htm b/gs/doc/Helpers.htm index 962f30edb..cc7997b2f 100644 --- a/gs/doc/Helpers.htm +++ b/gs/doc/Helpers.htm @@ -300,7 +300,7 @@ contact Artifex Software, Inc., 101 Lucas Valley Road #110, San Rafael, CA 94903, U.S.A., +1(415)492-9861. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History1.htm b/gs/doc/History1.htm index 8fc98b8b9..c0fdcedfb 100644 --- a/gs/doc/History1.htm +++ b/gs/doc/History1.htm @@ -430,7 +430,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History2.htm b/gs/doc/History2.htm index 1cb2d2f75..bb3c2ef88 100644 --- a/gs/doc/History2.htm +++ b/gs/doc/History2.htm @@ -5224,7 +5224,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History3.htm b/gs/doc/History3.htm index e631b5336..678f7bcf0 100644 --- a/gs/doc/History3.htm +++ b/gs/doc/History3.htm @@ -8589,7 +8589,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History4.htm b/gs/doc/History4.htm index 0df41d2a3..607dec26d 100644 --- a/gs/doc/History4.htm +++ b/gs/doc/History4.htm @@ -3973,7 +3973,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History5.htm b/gs/doc/History5.htm index 3a045908f..28a8debef 100644 --- a/gs/doc/History5.htm +++ b/gs/doc/History5.htm @@ -13447,7 +13447,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History6.htm b/gs/doc/History6.htm index bf6c654c3..3cd9a76ba 100644 --- a/gs/doc/History6.htm +++ b/gs/doc/History6.htm @@ -7329,7 +7329,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History7.htm b/gs/doc/History7.htm index 2c792245c..dc7ed3c82 100644 --- a/gs/doc/History7.htm +++ b/gs/doc/History7.htm @@ -15715,7 +15715,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History8.htm b/gs/doc/History8.htm index e89f6b341..37fb7cccd 100644 --- a/gs/doc/History8.htm +++ b/gs/doc/History8.htm @@ -62049,7 +62049,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/History9.htm b/gs/doc/History9.htm index cb689fb62..867dfc8de 100644 --- a/gs/doc/History9.htm +++ b/gs/doc/History9.htm @@ -29,6 +29,7 @@ <h2>Table of contents</h2> <blockquote><ul> +<li><a href="#Version9.02">Version 9.02 (2011-03-28)</a> <li><a href="#Version9.01">Version 9.01 (2011-02-07)</a> <li><a href="#Version9.00">Version 9.00 (2010-09-14)</a> </ul></blockquote> @@ -62,6 +63,2027 @@ overview</a>. <!-- [1.0 end visible header] ============================================== --> <!-- [2.0 begin contents] ================================================== --> +<h2><a name="Version9.02"></a>Version 9.02 (2011-02-07)</h3> + +<p>This is the third release in the stable 9.x series. + +<p>This is an "out of order" release, primarily to ensure the +GPL Ghostscript release remains in version "lock-step" with the +Artifex commercial release. + +<p> Highlights in this release include: + +<p>For monochrome devices, there is a new halftone technique for sampled +image data. The existing technique is very efficient (and is is still used) +for large areas of color, such as an area fill, but encountered performance +problems dealing with sampled image data where a given colour value only +covered a few pixels at a time. The new approach applies the halftone threshold +array directly to the image samples. + +<p> Further performance, memory use, and stability improvements with the new +features introduced in 9.00, as well as Unix/Linux build fixes, plus the usual +assorted bug fixes. + +<p>For a list of open issues, or to report problems, +please visit <a href="http://bugs.ghostscript.com/">bugs.ghostscript.com</a>. + +<h3><a name="9.02_Incompatible_changes"></a>Incompatible changes</h3> + +<p> +No recorded incompatible changes. + + + +<p><strong><a name="2011-03-28T084948.387061Z"></a> +2011-03-28T08:49:48.387061Z Chris Liddell</strong></p> +<blockquote> +<pre> +Reduce duplication of changelog and news by deprecating Changes.htm and +Details#.htm. + +The information will now be in two places only: the highlights summary +in News.htm, and the detailed changes in History#.htm. + +Update related documentation and html links to reflect this change. + +CLUSTER_UNTESTED +</pre> +<p>[doc/Changes.htm doc/Readme.htm doc/Details9.htm doc/Release.htm]</p> +</blockquote> + +<p><strong><a name="2011-03-26T145106.549590Z"></a> +2011-03-26T14:51:06.549590Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for issue found by Chris where we have a soft mask embedded in a softmask +and graphic state pushes and pops occurring. In this case, the soft mask stack +that is saved gets out of sync compared to the one in the context state. +Use of the stack count can catch the issue and correct it. Also a rename of +one of the variables in the pdf14 code to make it easier to debug.</pre> +<p>[base/gdevp14.c base/gdevp14.h]</p> +</blockquote> + +<p><strong><a name="2011-03-25T121205.657797Z"></a> +2011-03-25T12:12:05.657797Z Till Kamppeter</strong></p> +<blockquote> +<pre> +Fixes concerning the compatibility of the OpenPrinting Vector ("opvp") +output device with Ghostscript 9.x. + +1. If there is any ICCColor based image in the PostScript input, GS crashes. +2. Fallback when path is too complex for some kinds of printers. This problem + already existed in GS 8.x. + +Thanks to Koji Otani from BBR Inc., Japan. + +</pre> +<p>[contrib/opvp/gdevopvp.c]</p> +</blockquote> + +<p><strong><a name="2011-03-25T102206.357287Z"></a> +2011-03-25T10:22:06.357287Z Chris Liddell</strong></p> +<blockquote> +<pre> +The code was erroneously attempting to get a glyph name for a case where +we already had a glyph index for a Truetype font. + +Add a check for object type before trying to get a string from a name object. + + +Bug 692095 + +No cluster differences expected. + +</pre> +<p>[psi/zfapi.c]</p> +</blockquote> + +<p><strong><a name="2011-03-24T172617.397320Z"></a> +2011-03-24T17:26:17.397320Z Chris Liddell</strong></p> +<blockquote> +<pre> +Resolve build issues with language_switch and UFST. + +I had (wrongly) assumed that the PCL/language_switch builds with UFST +and COMPILE_INITS=1 would have the relevant paths correctly setup for +the PS/PDF world to access the Microtype FCOs. It turns out they are +done in an incompatible manner. + +So, I've renamed the path variables (in the makefiles) so there isn't +a clash between PCL and PS/PDF, ensured that the variables are correctly +passed through recursive (n)make calls, and tidied up the FAPI options +for the language_switch build. + +Not only does this allow language_switch to build with the UFST, but the +Postscript interpreter does now use FAPI/UFST to access the Microtype fonts +for the built-in fonts, and uses FAPI/Freetype for downloaded fonts. + +Bug 692093 + +No cluster differences expected. + +</pre> +<p>[/trunk/ghostpdl/common/msvc_top.mak /trunk/ghostpdl/language_switch/pspcl6_msvc.mak /trunk/ghostpdl/main/pcl6_gcc.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p> +</blockquote> + +<p><strong><a name="2011-03-24T042223.459616Z"></a> +2011-03-24T04:22:23.459616Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for compiler warning.</pre> +<p>[base/gdevp14.h]</p> +</blockquote> + +<p><strong><a name="2011-03-23T213420.429081Z"></a> +2011-03-23T21:34:20.429081Z Michael Vrhel</strong></p> +<blockquote> +<pre> +This commit fixes several issues. + +Memory leaks in the PDF14 device as well as the separation devices. +Fixes in PDF14 device so the the color encoder and decoder are properly updated +if soft masks occur with spot colors. +Proper copying of the devicen parameters to the clist devices in the MT +rendering. This was the source of a problem when doing multi-threaded +rendering to separation devices. + +This fixes bug 692087</pre> +<p>[base/gdevp14.c base/gsicc_cache.c base/gxclutil.c base/gdevpsd.c base/lib.mak base/gdevp14.h base/gxclthrd.c base/gdevtsep.c base/gdevdevn.c base/gxblend.c base/gdevdevn.h]</p> +</blockquote> + +<p><strong><a name="2011-03-21T112417.021832Z"></a> +2011-03-21T11:24:17.021832Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for memory leaks in the pdf14 device. These could occur with softmask and +graphic state changes as well as when we are going to a tiffsep device. </pre> +<p>[base/gdevp14.c]</p> +</blockquote> + +<p><strong><a name="2011-03-20T014019.345427Z"></a> +2011-03-20T01:40:19.345427Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for bug 692087 crashes. num_bytes - bytes_dropped was ending up negative +in cases where the transparency device was reducing the number of colorants +compared to the target device (mainly when we had a softmask) which was getting +passed into the clist as an unsigned value. Now when this occurs we just use +the encoding of the full color value. </pre> +<p>[base/gxclutil.c]</p> +</blockquote> + +<p><strong><a name="2011-03-19T045652.259544Z"></a> +2011-03-19T04:56:52.259544Z Michael Vrhel</strong></p> +<blockquote> +<pre> +A temp fix for bugs 692038 and 692065. The clist devices that are created for +the threads now inherit the icc profile from the target device. I need to set +things up so that the device profile is no longer reference counted since we +could have a race condition problem if the different threads are incrementing +and decrementing the count and if the command is not atomic on a particular +architecture. The plan will be to no longer ref count the device profile but +to have it maintained until the the actual target device is destroyed. There +will be a bit of work to do with respect to the pdf14 device, which can have +a device profile that is different than the actual target device. That profile +can be altered with the transparency group pushes and pops.</pre> +<p>[base/gxclthrd.c]</p> +</blockquote> + +<p><strong><a name="2011-03-19T003237.910024Z"></a> +2011-03-19T00:32:37.910024Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix for some strange rendering with PDF 1.7 FTS files when we have shading and +transparency and are both filling and stroking text (Text Rendering modes 2 +and 6). Customer 532. + +</pre> +<p>[Resource/Init/pdf_ops.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-18T051608.669973Z"></a> +2011-03-18T05:16:08.669973Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix so that image_parent_type is properly initialized during clist image +reading.</pre> +<p>[base/gsiparm4.h base/gximage1.c base/gximage4.c]</p> +</blockquote> + +<p><strong><a name="2011-03-17T152458.552348Z"></a> +2011-03-17T15:24:58.552348Z Chris Liddell</strong></p> +<blockquote> +<pre> +Escape/quote the UFST path settings in the makefile so that the macros +correctly expand to strings. + +Bug 692082 + +No cluster differences expected + +CLUSTER_UNTESTED +</pre> +<p>[base/Makefile.in]</p> +</blockquote> + +<p><strong><a name="2011-03-17T095453.062174Z"></a> +2011-03-17T09:54:53.062174Z Chris Liddell</strong></p> +<blockquote> +<pre> +Uncached glyphs were ignoring rendering mode 3, and being imaged +directly to the device - for cached glyphs the decision occurred +in the "show machinery". + +This wasn't my first choice solution, but all the others I tried +caused problems with later use of a cached glyph (which wasn't +actually cached), or problems with pdfwrite, pswrite or ps2write. + + +Bug 692004 + +No cluster differences expected. + +</pre> +<p>[base/gspaint.c]</p> +</blockquote> + +<p><strong><a name="2011-03-17T094116.074991Z"></a> +2011-03-17T09:41:16.074991Z Chris Liddell</strong></p> +<blockquote> +<pre> +Fix some issue where user specified devices didn't get the requisite +"$(DD)" and ".dev" runes added to them. + +Also, rearrange the "pre-declared" device strings to be more +consistent within configure.ac + + +Bug 692062 + +No cluster differences expected. + + +</pre> +<p>[base/configure.ac]</p> +</blockquote> + +<p><strong><a name="2011-03-15T175917.340024Z"></a> +2011-03-15T17:59:17.340024Z Robin Watts</strong></p> +<blockquote> +<pre> +Add special case mem_planar_copy_color_4to1 code for copying bits +from 4 1 bit planes into 1 4 bit chunky plane. + +This helps with performance of the plibk device. + +No cluster differences expected.</pre> +<p>[base/gdevmpla.c]</p> +</blockquote> + +<p><strong><a name="2011-03-15T083505.386182Z"></a> +2011-03-15T08:35:05.386182Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix (ps2write) : Indexed colour images have incorrect /Decode + +Bug #691924 "Differences in colour with ps2write" + +The problem was due to the opdfread code generating a /Decode for an Indexed +colour space where the value was [0 2^n] and should be [0 ((2^n) - 1)]. This +caused the highest image sample to be mapped to 1 past the end of the samples +in the colour space. + +Normally this doesn't matter, because the values are clamped to 'hival' in the +Indexed space. In this case, however, the image was 2 bpp (4 values) but the +colour space was defined as a full 256 indices, with only the first 4 bein +used. + +The incorrect Decode caused the image sample value 3 to be looked up as colour +space sample 4, which was set to all 0 (black) causing incorrect colour values. + +</pre> +<p>[base/opdfread.h lib/opdfread.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-14T154615.599171Z"></a> +2011-03-14T15:46:15.599171Z Robin Watts</strong></p> +<blockquote> +<pre> +Reintroduce commented out PACIFY_VALGRIND definition in gximono.c - without it +the comment makes no sense. + +Add new PACIFY_VALGRIND code (and commented out definition) in +gxht_threshold.c. + +Fix some line endings. + +No real code change, so no cluster differences expected. + +</pre> +<p>[base/gximono.c base/gxht_thresh.c]</p> +</blockquote> + +<p><strong><a name="2011-03-14T151608.036660Z"></a> +2011-03-14T15:16:08.036660Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix an indetermism in the halftoning code. When mapping a y offset into a +row index for a halftone tile, special care needs to be taken when y is +negative. Proof (as if more were needed) that the % operator in C is evil. + +The command in question was a cutdown version of C306.bin rendered at 600bpi +to pbmraw with dMaxBitmap=10000. + +It now runs into a clist UMR. Will keep looking.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-14T135351.702509Z"></a> +2011-03-14T13:53:51.702509Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix (ps2write) : Don't set a default halftone. + +Bug #691923 "Differences in dithered output with ps2write" + +The PDF interpreter emits a setpagdevice between every page of output, in case +the media size has changed. The implementation of setpagedevice resets the +halftone to be the default halftone (106 lpi 45 degree line screen). + +This is a problem for ps2write, and potantially pdfwrite, as there is no way to +differentiate between a default halftone set by setpagdevice, and a halftone +contained in the input file. + +To avoid embedding an unhelpful halftone, we now check the device parameter +'/HighLevelDevice' in the setpagedevice implementation, and if it is present +and true, we do not call .setdefaulthalftone. + +Also updates documentation on device parameters. + +This causes differences on every 1-bit rendering test (ie pkmraw) of the +ps2write output file, so approximately 1300 differences are to be expected. +</pre> +<p>[doc/Drivers.htm Resource/Init/gs_setpd.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-14T130003.503443Z"></a> +2011-03-14T13:00:03.503443Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix Bug 692064. Tiffscaled device was checking on page print time that the +expected size of the page wouldn't make the page too large to fit in a file. +This code was copied from the tiffgray device (as we render internally in +8bpp). As we output in monochrome however (and may use compression) the +test is in fact bogus, and should simply be removed. We do that here. + +It's entirely possible that we should be removing the test from the +tiffgray device too - most systems with 32bit longs support large files these +days, and compression may apply here too anyway. I'll leave this until it +becomes an issue though. + +No cluster differences expected.</pre> +<p>[base/gdevtsep.c]</p> +</blockquote> + +<p><strong><a name="2011-03-13T115708.378919Z"></a> +2011-03-13T11:57:08.378919Z Ken Sharp</strong></p> +<blockquote> +<pre> +Some updates to the new device parameters. It turned out that the intended +parameter Type32ToUnicode was incorrectly implemented. This should actually +have used the WantsToUnicode parameter, because the code actually controls the +processing of GlyphNames2Unicode tables from Windows PostScript. + +This means we no longer need the Type32ToUnicode parameter and it has been +removed. + +Added initial documentation of these parameters. + +This appears to cause some differences in Bug690829.ps rendered at 300 dpi. +This is a surprise, because the changes should have no effect on devices other +than pdfwrite/ps2write, but the new result is better than the old, so this is +a progression. +</pre> +<p>[Resource/Init/gs_pdfwr.ps base/gdevpdfx.h base/gdevpdfp.c doc/Drivers.htm base/gdevpdfb.h]</p> +</blockquote> + +<p><strong><a name="2011-03-13T012149.785339Z"></a> +2011-03-13T01:21:49.785339Z Ray Johnston</strong></p> +<blockquote> +<pre> +Remove spurious debug printout inserted in rev 12141 line 780: + 1 index == 0 index == +</pre> +<p>[Resource/Init/pdf_draw.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-11T192457.067395Z"></a> +2011-03-11T19:24:57.067395Z Ken Sharp</strong></p> +<blockquote> +<pre> +Change the default value for the 'AllowPSRepeat' so that it defaults to allowed +instead of disallowed (doh!) This is important for those devices which don't +set the device parameter. + +No differences expected. +</pre> +<p>[psi/zfunc4.c]</p> +</blockquote> + +<p><strong><a name="2011-03-11T171451.124213Z"></a> +2011-03-11T17:14:51.124213Z Ken Sharp</strong></p> +<blockquote> +<pre> +Remove a #if 0 accidentally left in the commit for revision 12282. Also +initialise a variable, just in case. + +No differences expected. +</pre> +<p>[psi/zfunc4.c]</p> +</blockquote> + +<p><strong><a name="2011-03-11T165834.690669Z"></a> +2011-03-11T16:58:34.690669Z Ken Sharp</strong></p> +<blockquote> +<pre> +The final removal of the reliance on testing the device name to influence +interpreter behaviour. + +This tests the /AllowPSRepeat paramter and flags an error if a function tries +to use 'repeat' when it is disallowed. + +Still to do: write some documentation on these new parameters. + +No differences expected. +</pre> +<p>[psi/zfunc4.c]</p> +</blockquote> + +<p><strong><a name="2011-03-11T151440.609962Z"></a> +2011-03-11T15:14:40.609962Z Chris Liddell</strong></p> +<blockquote> +<pre> +Add the new third party library directories to the Windows nmake zip file +target. + +No cluster differences. + +Bug 691944 + +Credit to: Gennadiy Tsarenkov. + +CLUSTER_UNTESTED + +</pre> +<p>[psi/winint.mak]</p> +</blockquote> + +<p><strong><a name="2011-03-11T150756.095474Z"></a> +2011-03-11T15:07:56.095474Z Chris Liddell</strong></p> +<blockquote> +<pre> +Rejig the romfs targets so that unix make can follow the dependencies. + +This should prevent the pointless rebuilding of the romfs C source. + +Bug 692053 + +No cluster differences expected. + +</pre> +<p>[base/lib.mak base/unix-aux.mak]</p> +</blockquote> + +<p><strong><a name="2011-03-11T090424.536166Z"></a> +2011-03-11T09:04:24.536166Z Chris Liddell</strong></p> +<blockquote> +<pre> +Some (broken) TrueType fonts have out of order loca tables, which can result +in the calculated glyph data lengths being larger than the actual +available glyph data. Normally this does not cause a problem, but if the glyph +in question is in the final bytes of the stream, we encounter an unexpected +end of data condition when creating the glyph data buffer to pass into +Freetype. + +So the FAPI interface code will now ignore that error, and adjust the byte +length to correctly reflect the number of bytes available in the buffer. + +It is safe to do this because, in the event we have a genuine out-of-data +condition, Freetype will return an error when it tries to interpret the +glyph outline. + +Bug 692043 + +No cluster differences expected. + +</pre> +<p>[psi/fapi_ft.c psi/zfapi.c]</p> +</blockquote> + +<p><strong><a name="2011-03-11T054519.450208Z"></a> +2011-03-11T05:45:19.450208Z Alex Cherepanov</strong></p> +<blockquote> +<pre> +Fix missing header problem on older versions of MSVC. +</pre> +<p>[base/gsropt.h]</p> +</blockquote> + +<p><strong><a name="2011-03-11T041539.316030Z"></a> +2011-03-11T04:15:39.316030Z Michael Vrhel</strong></p> +<blockquote> +<pre> +A reorganization of the halftone code in preparation of doing thresholding of +color images. This basically pulls out some code pieces that will be shared +in all the image thresholding cases. No differences expected +(or seen in the cluster push).</pre> +<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gxicolor.c base/gxht_thresh.c]</p> +</blockquote> + +<p><strong><a name="2011-03-10T173138.501799Z"></a> +2011-03-10T17:31:38.501799Z Robin Watts</strong></p> +<blockquote> +<pre> +I missed one change in commit 12274. The detection of chunky modes should +look at num_planes being <= 1, not == 1. + +I tested this locally and then clearly missed it when cluster pushing. +</pre> +<p>[base/gdevdrop.c]</p> +</blockquote> + +<p><strong><a name="2011-03-10T165615.200283Z"></a> +2011-03-10T16:56:15.200283Z Robin Watts</strong></p> +<blockquote> +<pre> +Planar device is broken w.r.t rops in a cmyk space - this commit fixes it. + +The planar memory device sets itself to use gx_default_strip_copy_rop +rather than mem_strip_copy_rop. mem_strip_copy_rop knows that rops on +cmyk pixels should actually convert to rgb, perform the rop, and convert +back again, but doesn't know how to convert the results back when it's in +planar mode. gs_default_strip_copy_rop can cope with planar mode, but doesn't +know to convert to rgb first. + +The first fix included here is to extend mem_strip_copy_rop to know how to +write back to planar format, and then to make the planar memory device use +mem_strip_copy_rop. + +This then exposes various flaws in mem_strip_copy_rop, including the fact +that it relies on being able to set the offset in get_bits calls when this +is sometimes not possible. We therefore fix the code to manage offsets +by explicitly updating them. + +Also, the raster used in mem_strip_copy_rop was incorrect - we use the +correct one and get much better results. + +No cluster differences expected as the planar device is not tested. + +</pre> +<p>[base/gdevdrop.c base/gdevmpla.c]</p> +</blockquote> + +<p><strong><a name="2011-03-10T164220.394889Z"></a> +2011-03-10T16:42:20.394889Z Robin Watts</strong></p> +<blockquote> +<pre> +The routines in gdevplib.c intended to map colors in cmyk form back to rgb +were incorrect. Fixed here. + +No differences expected as this files isn't linked in by default. + +CLUSTER_UNTESTED + + +</pre> +<p>[base/gdevplib.c]</p> +</blockquote> + +<p><strong><a name="2011-03-10T162704.913812Z"></a> +2011-03-10T16:27:04.913812Z Robin Watts</strong></p> +<blockquote> +<pre> +Remove the buffer blanking done in gximono.c. Previously removing this would +have caused indeterminisms. With the additional fix in here to limit +offset_bits to dest_width, however, we should get stable results. + +This gives various differences in output (81 in pcl, presumably more in PDF +and PS). Bmpcmp of the pcl ones shows them as all progressions. + +</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-10T145508.103488Z"></a> +2011-03-10T14:55:08.103488Z Ken Sharp</strong></p> +<blockquote> +<pre> +Update the remaining PostScript files (mostly the PDF interpreter) to use the +new device parameters instead of explicitly checking for the device being named +'pdfwrite' or 'ps2write'. + +Some more modification is still required, but we're nearly there. We will +continue to check the device names in gs_pdfwr.ps when setting up the default +state for those specific devices. + +Although not strictly a Distiller device, ps2write declares itself to be +'IsDistiller'. This is because some PostScript test files were found to behave +differently if the distillerparams operators were available, in particular +files would be oriented differently if the device was deemed to be a Distiller. + +</pre> +<p>[Resource/Init/gs_pdfwr.ps Resource/Init/pdf_font.ps Resource/Init/pdf_draw.ps base/gdevpdfb.h Resource/Init/gs_setpd.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-10T073145.990562Z"></a> +2011-03-10T07:31:45.990562Z Alex Cherepanov</strong></p> +<blockquote> +<pre> +Ignore null object when it is used instead of the gstate dictionary. +Bug 692050. +</pre> +<p>[Resource/Init/pdf_main.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-10T061917.004672Z"></a> +2011-03-10T06:19:17.004672Z Alex Cherepanov</strong></p> +<blockquote> +<pre> +Change all instances of true, false, and null to //true, //false, and //null +to avoid interferance from PS files that redefine them. Bug 692041. +</pre> +<p>[Resource/Init/gs_typ32.ps Resource/Init/gs_cidfm.ps Resource/Init/gs_mgl_e.ps Resource/Init/pdf_rbld.ps Resource/Init/gs_resmp.ps Resource/Init/gs_dscp.ps Resource/Init/gs_fonts.ps Resource/Init/gs_wan_e.ps Resource/Init/gs_mex_e.ps Resource/Init/gs_ttf.ps Resource/Init/gs_cspace.ps Resource/Init/gs_cff.ps Resource/Init/gs_dps1.ps Resource/Init/gs_lev2.ps Resource/Init/pdf_sec.ps Resource/Init/gs_l2img.ps Resource/Init/gs_cet.ps Resource/Init/gs_dbt_e.ps Resource/Init/gs_pdf_e.ps Resource/Init/gs_statd.ps Resource/Init/gs_fapi.ps Resource/Init/gs_pdfwr.ps Resource/Init/gs_cidfn.ps Resource/Init/pdf_main.ps Resource/Init/gs_dps.ps Resource/Init/gs_res.ps Resource/Init/gs_ll3.ps Resource/Init/gs_css_e.ps Resource/Init/gs_epsf.ps Resource/Init/pdf_draw.ps Resource/Init/gs_dpnxt.ps Resource/Init/gs_icc.ps Resource/Init/gs_mro_e.ps Resource/Init/pdf_ops.ps Resource/Init/gs_init.ps Resource/Init/pdf_font.ps Resource/Init/gs_ciddc.ps Resource/Init/gs_trap.ps Resource/Init/gs_cidtt.ps Resource/Init/gs_diskn.ps Resource/Init/gs_fntem.ps Resource/Init/pdf_base.ps Resource/Init/gs_sym_e.ps Resource/Init/gs_img.ps Resource/Init/gs_btokn.ps Resource/Init/gs_cidcm.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-10T005808.762234Z"></a> +2011-03-10T00:58:08.762234Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for bug 692038. + +This fixes 3 issues when using a CIELAB based profile for the output device ICC profile. + +One was a problem when handling separation color spaces when they had the ALL entry and we were going to an additive device. AR does a 1-INK level for the device values and no color management. We were doing the same, but this approach will not work if our destination color space is CIELAB. Now if we are headed toward CIELAB we do the 1-INK to RGB and then transform to CIELAB. + +Another was that transparency blending should never be done in CIELAB or similar type color spaces. With transparency, the PDF14 device inherits the profile for the target device and if the transparency groups don't specify a color space we would end up blending in CIELAB. The solution was to detect this situation and use the defaultRGB profile for blending. Conversion to CIELAB occurs during the pdf14 put image operation. + +Finally, with shading in transparency, we need to make sure to pass along the transparency device through the shading parameters whenever we have a color mismatch between the pdf14 device and the target device so that the shading will occur in the proper color space. + +These changes are all related to a non-tested cluster case when we have -sOutputICCProfile=lab.icc</pre> +<p>[base/gdevp14.c base/gxcmap.c base/gstrans.c base/gxclist.h base/gdevtfnx.c base/gsfunc0.c base/devs.mak base/gsicc.c]</p> +</blockquote> + +<p><strong><a name="2011-03-09T213258.461339Z"></a> +2011-03-09T21:32:58.461339Z Robin Watts</strong></p> +<blockquote> +<pre> +Add gxht_thresh.{c,h} to Visual C project. + +CLUSTER_UNCHECKED</pre> +<p>[ghostscript.vcproj]</p> +</blockquote> + +<p><strong><a name="2011-03-09T144440.068733Z"></a> +2011-03-09T14:44:40.068733Z Robin Watts</strong></p> +<blockquote> +<pre> +Disable PACIFY_VALGRIND in gximono.c. This define is intended to enable +extra code that can be performed so as to ensure that valgrind doesn't +report false positives. As such, disabling it should have no adverse +effects. + +Unfortunately, it seems that in the portrait case, if we don't blank the +threshold array before we run, we get diffs. I have therefore taken this +memset out of the PACIFY_VALGRIND case and forced it to always happen. +This probably points to a bug and should be investigated properly. + +No cluster differences expected. + +</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-08T200017.821965Z"></a> +2011-03-08T20:00:17.821965Z Robin Watts</strong></p> +<blockquote> +<pre> +Simple optimisations to non SSE2 versions of halftoning code. There is +probably (certainly!) more performance to come with loop unrolling etc, +but this at least gets us the cheap win of avoiding repeated array accessing, +only setting, not blanking bits etc. + +Cluster tests show no changes. + +</pre> +<p>[base/gxht_thresh.c]</p> +</blockquote> + +<p><strong><a name="2011-03-08T174051.077420Z"></a> +2011-03-08T17:40:51.077420Z Robin Watts</strong></p> +<blockquote> +<pre> +Change to gsroprun1.h to avoid over/underreading the source/texture buffers. + +Given a valid byte range we expand that to the smallest enclosing CHUNK range +and guarantee never to access out of that range. Previously we could read +one CHUNK before/after it. + +If this is a problem, simply ensure that CHUNK is byte rather than int on +your platform. This now behaves better than the original code which would +access one byte before/after the defined range. + +No cluster differences seen in testing. + +</pre> +<p>[base/gsroprun1.h]</p> +</blockquote> + +<p><strong><a name="2011-03-08T163516.023687Z"></a> +2011-03-08T16:35:16.023687Z Tor Andersson</strong></p> +<blockquote> +<pre> +Add PNG reading support to the bmpcmp tool.</pre> +<p>[toolbin/bmpcmp.c]</p> +</blockquote> + +<p><strong><a name="2011-03-08T151842.397978Z"></a> +2011-03-08T15:18:42.397978Z Ken Sharp</strong></p> +<blockquote> +<pre> +Update to use the new device parameter /PreserveTrMode instead of explicitly checking +for the device name being 'pdfwrite'. + +No differences expected. +</pre> +<p>[Resource/Init/pdf_ops.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-08T082754.788378Z"></a> +2011-03-08T08:27:54.788378Z Ken Sharp</strong></p> +<blockquote> +<pre> +Activate the new device parameters, and modify the resource code to use the first one +(AllowIncrementalCFF) instead of testing for the pdfwrite device name. + +No differences expected. +</pre> +<p>[Resource/Init/gs_cidfn.ps base/gdevpdfp.c]</p> +</blockquote> + +<p><strong><a name="2011-03-08T002607.330315Z"></a> +2011-03-08T00:26:07.330315Z Robin Watts</strong></p> +<blockquote> +<pre> +When using PACIFY_VALGRIND, don't call the memory blanking when the +mallocs have failed. + +This should cure the SEGVs that were introduced, but otherwise cause no +changes. + +</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T221929.253652Z"></a> +2011-03-07T22:19:29.253652Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Initialize ht landscape structure to zero when in portrait case. There is a conditional test on the value later.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T215702.879011Z"></a> +2011-03-07T21:57:02.879011Z Robin Watts</strong></p> +<blockquote> +<pre> +Correct line endings (were DOS, should be Unix). + +No cluster differences. + +CLUSTER_UNTESTED + +</pre> +<p>[base/gxht_thresh.h base/gxht_thresh.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T211712.494498Z"></a> +2011-03-07T21:17:12.494498Z Robin Watts</strong></p> +<blockquote> +<pre> +Add new debugging define to gximono.c, PACIFY_VALGRIND. + +This enables various small tweaks in the code that stop valgrind throwing +errors. We believe that all the errors thrown are false positives, but +we enable this define anyway until we've sorted the current indeterminisms. +We'll disable it in a few days when we have solved the problems and check that +it really doesn't cause any more. + +Cluster results unknown; probably no change. If this solves indetermisms +then we'll need to understand why. + +</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T211156.916525Z"></a> +2011-03-07T21:11:56.916525Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix typos, one in a comment, one in an id string. + +No cluster differences. + +CLUSTER_UNTESTED + +</pre> +<p>[base/gxipixel.c base/gzspotan.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T185808.149818Z"></a> +2011-03-07T18:58:08.149818Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for improper indexing of reversed portrait image line. We were off by one byte and ended up with one byte not set. Def. a source of indeterminism. Thanks to Robin for tracking this down.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T154013.201330Z"></a> +2011-03-07T15:40:13.201330Z Ken Sharp</strong></p> +<blockquote> +<pre> +Undo revision 12243. The revision makes a debug print dependent on the value of the + 'size_set' variable. Unfortunately, this variable is not defined in the cups_get_matrix +routine. It is defined in the other places it is used (cups_put_params). + +This prevents a debug build from compiling on Windows, and I can't see how it would +work on any other OS when built for debug. + +Reverted the change in order to build debug versions of Ghostscript. +</pre> +<p>[cups/gdevcups.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T142111.345196Z"></a> +2011-03-07T14:21:11.345196Z Ken Sharp</strong></p> +<blockquote> +<pre> +Redo revision 12248 in a way which (hopefully!) doesn't cause seg faults. + +Still no differences expected.... +</pre> +<p>[base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]</p> +</blockquote> + +<p><strong><a name="2011-03-07T124047.052280Z"></a> +2011-03-07T12:40:47.052280Z Chris Liddell</strong></p> +<blockquote> +<pre> +Account for fonts in which (some) charstrings have been replaced with +Postscript procedures when FAPI decides an outline, or just a width +is required. The previous code only handled this case for rendered +glyphs from Freetype. + +Bug 692029 + +No cluster differences expected. + + + +</pre> +<p>[psi/zfapi.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T111219.973357Z"></a> +2011-03-07T11:12:19.973357Z Ken Sharp</strong></p> +<blockquote> +<pre> +pdfwrite & ps2write enhancement + +Add some new keys to the device parameters dictionary for these devices. These will be +used to replace the explicit tests against the device name in various places in future +commits. + +These will also later be documented and their use suggested for any devices requiring +the same capabilities. + +No differences expected, these are not used yet.</pre> +<p>[base/gdevpdfp.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T094302.986503Z"></a> +2011-03-07T09:43:02.986503Z Chris Liddell</strong></p> +<blockquote> +<pre> +Update the second place where we may have to reset the Freetype glyph object. + +Again, this means we only free the outline or bitmap data, and just let +Freetype "reset" its glyph object between glyphs. + +No cluster differences expected. + +</pre> +<p>[psi/fapi_ft.c]</p> +</blockquote> + +<p><strong><a name="2011-03-07T070812.439689Z"></a> +2011-03-07T07:08:12.439689Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix for compositor device chaining in the pdf14 device. This was detected in a +file that did overprint along with transparency. The pdf14 device incremented the +ref_count for the overprint_device, but never decremented it since the 'finalize' +of the pdf14 device was left at NULL rather than being set to the gx_forward_finalize +function which should be used. The gx_device_set_target, rather than rc_assign does +the proper set of the finalize proc pointer so that reference counts for the device +chain are properly maintained. Detected by customer 532 since their device freed +the clist buf_device resulting in the overprint_device having a 'target' pointer +to freed memory, causing a SEGV when the 'finalize' function executed. + +No regressions expected since in the normal code, the GC frees the devices that +were left unreferenced by the free of the pdf14 device. +</pre> +<p>[base/gdevp14.c]</p> +</blockquote> + +<p><strong><a name="2011-03-06T165219.765042Z"></a> +2011-03-06T16:52:19.765042Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix to use proper DDA incrementation for interpolation. We still maintain special loops for when there is no scaling or for when it is 2x. This should fix the intdeterminism issues. Tested performance on customer files and no significant difference was observed. About 1500 cluster differences will be reported with this fix.</pre> +<p>[base/lib.mak base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-06T111548.120325Z"></a> +2011-03-06T11:15:48.120325Z Chris Liddell</strong></p> +<blockquote> +<pre> +Instead of destroying and recreating freetype's glyph object for every glyph +we need to render, we can just free the "transient" parts: the bitmap or the +outline. + +Saves a very small amount of time, and potentially reduces memory pool +fragmentation. + +No cluster differences expected. + +</pre> +<p>[psi/fapi_ft.c]</p> +</blockquote> + +<p><strong><a name="2011-03-05T174646.608714Z"></a> +2011-03-05T17:46:46.608714Z Till Kamppeter</strong></p> +<blockquote> +<pre> +Do not do debug output of an uninitialized variable + +Thanks to Richard Hughes (hughsient at gmail dot com) for the patch. + +</pre> +<p>[cups/gdevcups.c]</p> +</blockquote> + +<p><strong><a name="2011-03-04T192750.114304Z"></a> +2011-03-04T19:27:50.114304Z Till Kamppeter</strong></p> +<blockquote> +<pre> +Correction on Richard Hughes' patch for color management in the CUPS filters. +</pre> +<p>[cups/colord.c]</p> +</blockquote> + +<p><strong><a name="2011-03-04T175100.067911Z"></a> +2011-03-04T17:51:00.067911Z Henry Stiles</strong></p> +<blockquote> +<pre> +Fix a warning and type error. Code should produce the same results, +so no testing. + +CLUSTER_UNTESTED + +</pre> +<p>[base/gdevdgbr.c]</p> +</blockquote> + +<p><strong><a name="2011-03-04T133411.568425Z"></a> +2011-03-04T13:34:11.568425Z Robin Watts</strong></p> +<blockquote> +<pre> +Add FIXME to gximono.c about possible future optimisation, so it is not +forgotten. + +CLUSTER_UNTESTED + +</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-04T093504.845642Z"></a> +2011-03-04T09:35:04.845642Z Chris Liddell</strong></p> +<blockquote> +<pre> +Only attempt to create files in the "cups" directory if it exists. +</pre> +<p>[base/configure.ac]</p> +</blockquote> + +<p><strong><a name="2011-03-04T064529.360251Z"></a> +2011-03-04T06:45:29.360251Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Reorganization of threshold code to move all the thresh holding operations into a new file. </pre> +<p>[base/gxht_thresh.h base/lib.mak base/gximono.c base/gximage.h base/gxht_thresh.c base/gsiparam.h]</p> +</blockquote> + +<p><strong><a name="2011-03-04T061653.560659Z"></a> +2011-03-04T06:16:53.560659Z Alex Cherepanov</strong></p> +<blockquote> +<pre> +Add missing test for /packedarraytype during recursive dereferencing +of composite PDF objects. Bug 692018, customer 850. +</pre> +<p>[Resource/Init/pdf_base.ps]</p> +</blockquote> + +<p><strong><a name="2011-03-03T222022.363870Z"></a> +2011-03-03T22:20:22.363870Z Henry Stiles</strong></p> +<blockquote> +<pre> +The get_bits() device call was assumed to return copied data and fill +in the allocated memory pointed to by the variable row, in fact the +gets_bit call can also just return a pointer and row is never +initialized, now we detect that. This broke raster operations for the +display device and appears to have resulted in the use of +uninitialized data in other files. A sampling of changed files showed +single pixel differences in files. + +</pre> +<p>[base/gdevdgbr.c]</p> +</blockquote> + +<p><strong><a name="2011-03-03T202923.683592Z"></a> +2011-03-03T20:29:23.683592Z Robin Watts</strong></p> +<blockquote> +<pre> +Update plibc and plibk to output pams when built with DEBUG_DUMP. + +No cluster differences possible as this code is not used in cluster testing. + +CLUSTER_UNTESTED</pre> +<p>[base/gdevplib.c]</p> +</blockquote> + +<p><strong><a name="2011-03-03T202343.920044Z"></a> +2011-03-03T20:23:43.920044Z Robin Watts</strong></p> +<blockquote> +<pre> +Add new pamcmyk4 device. Identical to pamcmyk32 device, but works in 1 bit +per component, rather than 8. + +No cluster differences expected as this code isn't tested.</pre> +<p>[psi/msvc.mak base/unix-gcc.mak base/gdevpbm.c base/devs.mak]</p> +</blockquote> + +<p><strong><a name="2011-03-03T175148.590954Z"></a> +2011-03-03T17:51:48.590954Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Enabling of thresholding code as default image rendering of monochrome/indexed images for monochrome devices. This will result in about 2432 differences reported. I stepped through them in a bmpcmp to check for serious issues. The minor halftone differences were due to the fact that we step in the device space for pixel replication in the threshold code but step in source space for the rect fill code. Enabling this code now will make it easier to track issues as we expand the use of the thresholding code.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-03-03T154846.192376Z"></a> +2011-03-03T15:48:46.192376Z Robin Watts</strong></p> +<blockquote> +<pre> +Add plib device (c and h) files to ghostscript project file. + +No cluster differences expected as project file is not used by cluster. + +CLUSTER_UNTESTED</pre> +<p>[ghostscript.vcproj]</p> +</blockquote> + +<p><strong><a name="2011-03-03T000827.251299Z"></a> +2011-03-03T00:08:27.251299Z Marcos H. Woehrmann</strong></p> +<blockquote> +<pre> +Added the ability to specify bmpcmp in addition to a normal clusterpush.pl +operation. Both commands will be queued in the correct order. + +Examples: + + ./clusterpush.pl gs bmpcmp + ./clusterpush.pl bmpcmp gs pcl xps ls + +Note that the order of the options is not signficant. + +The command line parser for clusterpush.pl changed signficantly with this +revision. It should be backwards compatible with the previous version +but it's possible that subtle differences exist. If a clusterpush.pl +command line behaves differently than you expect please open a bug. + +</pre> +<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/clusterpush.pl toolbin/localcluster/clusterpush.txt]</p> +</blockquote> + +<p><strong><a name="2011-03-02T221239.208205Z"></a> +2011-03-02T22:12:39.208205Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix rop operation on plib device. Previously, I'd disabled get_bits_rectangle +on the buffer device as the data is normally in the format we need it in +anyway, so it's a NOP. Unfortunately it's needed for rop operation, so +reintroduce it. + +To avoid infinite loops, we have to cope with GB_RETURN_POINTER. This is +easy to add to the gdevmpla.c device, but it's less clear that adding it +into the mem device is the right thing to do. We therefore introduce a +shim function to cope with GB_RETURN_POINTER with the mem device. + +No cluster differences expected as this is disabled by default. + +Testing shows that the planar device is now very close to the non planar +equivalent.</pre> +<p>[base/gdevplib.c base/gdevmpla.c]</p> +</blockquote> + +<p><strong><a name="2011-03-02T205046.635530Z"></a> +2011-03-02T20:50:46.635530Z regression</strong></p> +<blockquote> +<pre> +Minor bug fixes and improvements to the cluster system, the most +signifcant of which is the addition of "CLUSTER_UNTESTED" detection. +If this keyword appears anywhere within the log message of a commit that +revision will not be tested by the cluster. + +Less interesting changes include: + + Fix for bmpcmp if large numbers of differences are produced + + Addition of 'svn cleanup' calls before 'svn update' to handle nodes that + crashed during previous 'svn update' and left the repositories locked + + Set status of all nodes to idle after jobs are completed. + + Fix bugs that caused bmpcmp completed emails to be appended to the + previous message. + +</pre> +<p>[toolbin/localcluster/clustermaster.pl toolbin/localcluster/pngs2html.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]</p> +</blockquote> + +<p><strong><a name="2011-03-02T185123.645025Z"></a> +2011-03-02T18:51:23.645025Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Introduction of a member variable in gs_image1_t, which will let us know the original source type of the image. For example if, the parent source were type3 this spawns two type1 images. One for the mask and one for the image data. The mask is rendered using image render simple. If the image is monochrome or indexed, it is rendered with the renderer in gximono.c . If we are going to a halftone monochrome device, we end up using the fast threshold based renderer which has its interpolation stepping in device space as opposed to source space. This causes very minor differences between the mask and the image data. To avoid this, we use the old rect_fill code for the image type3 data to ensure a more exact spatial match.</pre> +<p>[base/gximono.c base/gximage1.c base/gximage2.c base/gximage3.c base/gximage4.c base/gximage.h base/gximag3x.c base/gsiparam.h]</p> +</blockquote> + +<p><strong><a name="2011-03-02T133952.433442Z"></a> +2011-03-02T13:39:52.433442Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix bmpcmp bug; the map array was being incorrectly sized, resulting in +occasional memory corruption. + +No cluster differences expected.</pre> +<p>[toolbin/bmpcmp.c]</p> +</blockquote> + +<p><strong><a name="2011-03-02T000925.760114Z"></a> +2011-03-02T00:09:25.760114Z Robin Watts</strong></p> +<blockquote> +<pre> +Debug output for gdevplibm (monochrome planar interlaced bands) was broken +and writing malformed pbms. Simple fix - move the mono output code to the +mono branch of the if rather than the grey one. + +No cluster differences expected.</pre> +<p>[base/gdevplib.c]</p> +</blockquote> + +<p><strong><a name="2011-03-01T193056.622647Z"></a> +2011-03-01T19:30:56.622647Z Robin Watts</strong></p> +<blockquote> +<pre> +Remove DOS line endings from .gitignore files.</pre> +<p>[.gitignore /trunk/ghostpdl/.gitignore]</p> +</blockquote> + +<p><strong><a name="2011-03-01T171830.158752Z"></a> +2011-03-01T17:18:30.158752Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for error introduced in non-SSE2 code when I removed the inclusion of the transfer function into the threshold values.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-02-28T223128.419926Z"></a> +2011-02-28T22:31:28.419926Z Till Kamppeter</strong></p> +<blockquote> +<pre> +Added color management support to the CUPS ...toraster filters + +Replaced the ...toraster filters by one filter executable, gstoraster, +written in C. This filter converts both PostScript and PDF input into +the CUPS Raster format using Ghostscript with the "cups" output +device, controlled by settings in the print queue's PPD file, by +command line options, and by settings embedded in a PostScript input +stream. This is now done with color management based on +printer-specific ICC profiles referenced in the PPD file or supplied +by the color management daemon colord. The CUPS PPD extensions +concerning color management +(http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html) are made +use of if used and the colord daemon is used if it is present. colord +is accessed via D-Bus, but the new filter can also be compiled without +D-Bus and in this case only the CUPS PPD extensions and ICC profiles +assigned to the print queue are used for color management. + +Thanks to Richard Hughes for the patch. + +</pre> +<p>[cups/pstoraster.in cups/pstoraster.convs cups/gstoraster.c cups/pdftoraster.c cups/cups.mak base/Makefile.in cups/colord.c base/configure.ac cups/gstoraster.convs cups/pdftoraster.convs cups/colord.h]</p> +</blockquote> + +<p><strong><a name="2011-02-28T203043.994348Z"></a> +2011-02-28T20:30:43.994348Z Robin Watts</strong></p> +<blockquote> +<pre> +X offset in custom 24 -> 888 planar copy_color routine was being miscalculated. +Simple fix. + +No cluster differences expected as this is untested.</pre> +<p>[base/gdevmpla.c]</p> +</blockquote> + +<p><strong><a name="2011-02-28T193534.539587Z"></a> +2011-02-28T19:35:34.539587Z Robin Watts</strong></p> +<blockquote> +<pre> +Remove silly debugging hack left in gdevmpla.c by accident. Only affects +planar 888 devices (i.e. none enabled by default). + +No cluster differences expected.</pre> +<p>[base/gdevmpla.c]</p> +</blockquote> + +<p><strong><a name="2011-02-28T193237.270892Z"></a> +2011-02-28T19:32:37.270892Z Robin Watts</strong></p> +<blockquote> +<pre> +Add simple .gitignore files.</pre> +<p>[.gitignore /trunk/ghostpdl/.gitignore]</p> +</blockquote> + +<p><strong><a name="2011-02-28T104811.852106Z"></a> +2011-02-28T10:48:11.852106Z Ken Sharp</strong></p> +<blockquote> +<pre> +Silence a compiler (scan-build) warning about a variable never being used.</pre> +<p>[base/gdevpdfo.c]</p> +</blockquote> + +<p><strong><a name="2011-02-28T052346.157854Z"></a> +2011-02-28T05:23:46.157854Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for mis-scale on decode for render mono cache. Fixes improper rendering of 148-11.ps with new halftone code.</pre> +<p>[base/gxipixel.c]</p> +</blockquote> + +<p><strong><a name="2011-02-27T232610.406657Z"></a> +2011-02-27T23:26:10.406657Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Removal (or inactivation) of code to include inverse of transfer function in the threshold values. Also minor fix for scaling issue in halftone code in portrait mode. Code is inactive so no regression diffs expected.</pre> +<p>[base/gximono.c base/gsht.c]</p> +</blockquote> + +<p><strong><a name="2011-02-27T232330.287293Z"></a> +2011-02-27T23:23:30.287293Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix for a bug that was introduced with the ICC branch. This was causing a mismatch between banded an unbanded rendering and in particular had rendering errors in banded mode when rendering PS and PDF files that had a non identity transfer function. Minor progression diffs in many files with very visible progressions in 246-01.ps, 258-01.ps as examples. What was happening is that when running in clist mode, we were not recognizing that a transfer function was present when doing the ICC branch. Stumble upon this working the transfer function in with the new threshold based halftoning code.</pre> +<p>[base/gxipixel.c]</p> +</blockquote> + +<p><strong><a name="2011-02-27T015228.834714Z"></a> +2011-02-27T01:52:28.834714Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix for PDF with ASCII85Decode filter that has a dictionary (even if empty) +instead of a 'null' for the params. Stack has the param dict second on the +stack, not third. Bug 692003, customer 700. +</pre> +<p>[Resource/Init/pdf_base.ps]</p> +</blockquote> + +<p><strong><a name="2011-02-26T191752.838303Z"></a> +2011-02-26T19:17:52.838303Z Till Kamppeter</strong></p> +<blockquote> +<pre> +TCUPS Raster driver: The macros in the cups_put_params() function +could access uninitialized variables when logging error messages and +this could lead to a segmentation fault, making Ghostscript crashing +and many jobs not printed. Debian bug #615202. + +</pre> +<p>[cups/gdevcups.c]</p> +</blockquote> + +<p><strong><a name="2011-02-26T184059.351498Z"></a> +2011-02-26T18:40:59.351498Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix for PDF 1.7 fts_08_0808.pdf which can clip the corner of the really wide +diagonal (magenta) stroke when banding is used. This was due to the 'extension' +of a square line cap being incorrectly calculated. Customer 532 issue. +</pre> +<p>[base/gxstroke.c]</p> +</blockquote> + +<p><strong><a name="2011-02-26T182508.170267Z"></a> +2011-02-26T18:25:08.170267Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix BUILD_SYSTEM conditional for 64 vs. 32 and add 'for Win64' message +to help avoid confusion during setup. +</pre> +<p>[psi/winint.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-25T235750.833144Z"></a> +2011-02-25T23:57:50.833144Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix bug reported by "new customer feb 2011", whereby gs 8.71 on an embedded +ppc platform is getting the colours on an image in a pdf wrong. + +Debugging shows that in gs_indexed_limit_and_lookup we take a floating point +value, clip it, convert it to an int and use it to lookup which colour to use. +On the reference x86 run we have a value of 1 (0x3f800000 as an IEEE float). +On the ppc we have 0.999999 (0x3f7fffff as an IEEE float). This tiny difference +results in values of 1 and 0 respectively when converted to the int, giving +the wrong colour. + +The fix here is to add a small epsilon before conversion. + +A quick experiment in adding 0.5 rather than epsilon shows worse results. + +15 cluster differences in testing, none that actually survived a bmpcmp. + + +</pre> +<p>[base/gscolor2.c]</p> +</blockquote> + +<p><strong><a name="2011-02-25T194939.160812Z"></a> +2011-02-25T19:49:39.160812Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Fix so that we only do the fast code if we are in portrait or landscape mode. Skewed objects will have to use the rect fill method.</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-02-25T193355.727547Z"></a> +2011-02-25T19:33:55.727547Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Addition of code to incorporate the inverse of the transfer curve into the threshold matrix. If the curve is an inverting type (e.g. 0 to 1 and 1 to 0) then a the thresholding comparison is switched. Also, if the curve is not monotonic, it can not be inverted and we revert to the old rect fill method. This commit has the code disabled so there should not be any regressions.</pre> +<p>[base/lib.mak base/gximono.c base/gzht.h base/gxdht.h base/gsht.c]</p> +</blockquote> + +<p><strong><a name="2011-02-25T181349.002375Z"></a> +2011-02-25T18:13:49.002375Z Ray Johnston</strong></p> +<blockquote> +<pre> +Set the GS_DLL to gsdll64.dll for a 64-bit build. The file list was correct, +but the registry was not. Related to bug 691975 but not verified (I just +checked the registry using regedit). +</pre> +<p>[psi/dwsetup.cpp]</p> +</blockquote> + +<p><strong><a name="2011-02-25T074221.024741Z"></a> +2011-02-25T07:42:21.024741Z Chris Liddell</strong></p> +<blockquote> +<pre> +Revise how the UFST setting are handled in the makefiles. + +The previous version relied on GNU make extensions (specifically +conditionals), whilst this version does not. + +No cluster differences expected. + +</pre> +<p>[base/lib.mak psi/msvc.mak base/Makefile.in psi/int.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-24T111312.751072Z"></a> +2011-02-24T11:13:12.751072Z Chris Liddell</strong></p> +<blockquote> +<pre> +Hopefully the final iteration of allowing SHARE_ZLIB +to work correctly with COMPILE_INITS=1. + +This version changes only Unix-like builds, so Windows need +not suffer, and also removes the reliance GNU make specific +extensions. + +Bug 691986 + + +No cluster differences. + +</pre> +<p>[base/unix-aux.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-24T005108.210054Z"></a> +2011-02-24T00:51:08.210054Z Robin Watts</strong></p> +<blockquote> +<pre> +Add new plib family of devices (PLanar Interlaced Buffer). These 5 devices +(plib = r8g8b8, plibg = g8, plibm = mono, plibc = c8m8y8k8, plibk = c1m1y1k1) +use a new 'band donor' interface to request a band buffer, pass back +rendered bands, and release bands at the end of the page. + +The idea is that other firmware can implement this simple interface, and +Ghostscript can thus easily drive systems that expect planar interlaced +input. + +On the whole there is relatively little new code here; the majority of the +work is done using the existing planar device with the odd tweak here and +there. Firstly, we lift the (artifical) constraints of the number of components +supported (so greyscale is accepted as a planar device for simplicity). +We spot the num_components = 1 case and just use the existing memory device +interface. + +Secondly, we add a fast 888chunky to 888planar unpacking routine for use +with copy_color. + +Within the plib device itself, we make use of the facility to set the line +indexes to allow for interlaced operation. It would be easy to extend this +device to offer planar non-interlaced operation too built on the same band +donor interface simply by omitting this code. + +For debugging purposes we have options within the plib devices to store the +data returned in each band into pxm files (as appropriate to the number of +components). This code is deactivated by default as the output of this +device is via the band donor interface, not the output file. + +No cluster differences expected as this code is disabled currently. + +Next job: discuss with Marcos how to cluster test this. + +</pre> +<p>[base/gdevplib.c base/gdevmpla.c base/gdevplib.h base/gdevppla.c base/devs.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-23T160025.505362Z"></a> +2011-02-23T16:00:25.505362Z Robin Watts</strong></p> +<blockquote> +<pre> +Introduce and enable 8 bit rop run templated code. + +No cluster differences shown. + +</pre> +<p>[base/gsroprun8.h base/lib.mak base/gsroprun.c ghostscript.vcproj]</p> +</blockquote> + +<p><strong><a name="2011-02-23T144145.053687Z"></a> +2011-02-23T14:41:45.053687Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Remove commented out code left over from commit 12192</pre> +<p>[base/lib.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-23T115400.145784Z"></a> +2011-02-23T11:54:00.145784Z Robin Watts</strong></p> +<blockquote> +<pre> +Reintroduce runrop changes to Visual Studio solution lost in recent merge +(r12189). + +No cluster differences expected. + +</pre> +<p>[ghostscript.vcproj]</p> +</blockquote> + +<p><strong><a name="2011-02-23T082540.039813Z"></a> +2011-02-23T08:25:40.039813Z Chris Liddell</strong></p> +<blockquote> +<pre> +Revision to the changes for using the system zlib. + +r12184 caused problems on Windows. + +This approach uses configure to determine whether +freetype should use the system zlib, based on whether +Ghostscript is using the system zlib. + +Windows, of course, doesn't use configure, so it will +never attempt to the use the system zlib. + +Bug 691986 + +No cluster differences expected + +</pre> +<p>[base/freetype.mak base/Makefile.in base/configure.ac]</p> +</blockquote> + +<p><strong><a name="2011-02-23T032618.063337Z"></a> +2011-02-23T03:26:18.063337Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Temporary fix to turn off fast code for cases where the bps of the index image is not 8bps</pre> +<p>[base/gximono.c]</p> +</blockquote> + +<p><strong><a name="2011-02-23T010908.645858Z"></a> +2011-02-23T01:09:08.645858Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Undo of rev 12184 by commenting out the changes for now. This change broke the windows build. </pre> +<p>[base/lib.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-22T213158.870907Z"></a> +2011-02-22T21:31:58.870907Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix warnings caused by merging the halftone branch to the trunk in r12189. + +No cluster differences expected. + +</pre> +<p>[base/gxipixel.c base/gximono.c base/gsht.c]</p> +</blockquote> + +<p><strong><a name="2011-02-22T200337.651092Z"></a> +2011-02-22T20:03:37.651092Z Robin Watts</strong></p> +<blockquote> +<pre> +Forgot this file inthe last commit. Sorry! + +</pre> +<p>[base/gsroprun24.h]</p> +</blockquote> + +<p><strong><a name="2011-02-22T195243.275685Z"></a> +2011-02-22T19:52:43.275685Z Michael Vrhel</strong></p> +<blockquote> +<pre> +Merge of halftone branch into the trunk. The new rendering code is actually disabled with this commit. As such, there should not be any testing differences.</pre> +<p>[base/gxipixel.c base/lib.mak base/Makefile.in base/gxcie.h /trunk/gs base/gsht.c base/gxcmap.c psi/msvc.mak ghostscript.vcproj base/gximono.c base/gzht.h base/gxidata.c base/configure.ac base/gxdht.h base/gxcmap.h base/gxicolor.c base/gximage.h base/gsciemap.c]</p> +</blockquote> + +<p><strong><a name="2011-02-22T193857.296889Z"></a> +2011-02-22T19:38:57.296889Z Robin Watts</strong></p> +<blockquote> +<pre> +Add templated 24bit rops. Clusterpushing seems to indicate this works. + +No cluster differences expected. + +</pre> +<p>[base/lib.mak base/gsroprun.c base/gsroprun1.h]</p> +</blockquote> + +<p><strong><a name="2011-02-22T161008.900201Z"></a> +2011-02-22T16:10:08.900201Z Chris Liddell</strong></p> +<blockquote> +<pre> +Tweak to allow compressed romfs to be built when we're configured +to use the system's zlib rather than our own. + +As a side effect of this, freetype is now configured to use the +same zlib instance as Ghostscript (instead of freetype's own +subset of zlib sources). + +Bug 691986 + +No cluster differences expected. + +</pre> +<p>[base/freetype.mak base/lib.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-22T154409.440053Z"></a> +2011-02-22T15:44:09.440053Z Robin Watts</strong></p> +<blockquote> +<pre> +Add new gsroprun files to Visual Studio solution. + +No cluster differences expected. + +</pre> +<p>[ghostscript.vcproj]</p> +</blockquote> + +<p><strong><a name="2011-02-22T152803.132855Z"></a> +2011-02-22T15:28:03.132855Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix DO_FILL_RECT_BY_COPY_ROP code, and enable it by default. + +The only thing wrong with the code before is the case when strip_tile_rectangle +is called with both color0 and color1 being gx_no_color_index. That translates +to rop=0xAA (i.e. D - no change). This is actually a special case that means +it's really doing a copy_color operation. We handle this by punting in the +same way as the old code used to. + +No cluster differences expected. + +</pre> +<p>[base/gdevm1.c]</p> +</blockquote> + +<p><strong><a name="2011-02-22T001816.845591Z"></a> +2011-02-22T00:18:16.845591Z Robin Watts</strong></p> +<blockquote> +<pre> +Enable mono_copy_mono implemented in terms of mono_copy_rop. + +Very small changes to the code to ensure that the copied area is correctly +clipped, this now gives identical results to the existing code, but should +be faster. + +The tile_rectangle code is still misbehaving - will fix this in later +revisions (I hope). + +No cluster differences expected. + +</pre> +<p>[base/gdevm1.c]</p> +</blockquote> + +<p><strong><a name="2011-02-21T171210.825257Z"></a> +2011-02-21T17:12:10.825257Z Robin Watts</strong></p> +<blockquote> +<pre> +Recommit of 12163 to the trunk. + +The fit_copy macro checks for the start address being off the top of the +screen, and clips it to zero. When it does this, it does: data -= y * raster, +which gives problems if raster is a uint ( as uint * int == uint in C) and +data is a 64 bit pointer. + +The fix is simply to cast the result to an int before using it. This solves +various SEGVs with the mono_copy_mono using mono_copy_rop code. + +No cluster differences expected. + +</pre> +<p>[base/gxdevice.h]</p> +</blockquote> + +<p><strong><a name="2011-02-21T160425.039434Z"></a> +2011-02-21T16:04:25.039434Z Chris Liddell</strong></p> +<blockquote> +<pre> +The structure containing the pthreads native elements making up a +gp_semaphore structure was ending up incorrectly aligned on +sparc32 Linux systems, and caused a bus error. Annoyingly, sparc32 +uses 32 bit pointers but requires 64 bit aligment. + +This change enforces maximum alignment for the elements of +gp_semaphore, for the current platform. + +No cluster differences expected. + +Bug 691989 + +</pre> +<p>[base/lib.mak base/gpsync.h]</p> +</blockquote> + +<p><strong><a name="2011-02-21T122920.951013Z"></a> +2011-02-21T12:29:20.951013Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix stupid typo in gsroprun.c that was causing templated rops to be different +to non templated rops. With this fixed the cluster shows identical results +(modulo indeterminisms), but the templated code is faster - so enable by +default. + +No cluster differences expected. + +</pre> +<p>[base/gsroprun.c]</p> +</blockquote> + +<p><strong><a name="2011-02-20T124120.382249Z"></a> +2011-02-20T12:41:20.382249Z Robin Watts</strong></p> +<blockquote> +<pre> +Initial reorganisation of code towards using copy_rops for copy_mono. + +Split the guts of mem_mono_strip_copy_rop out into a separate function +mem_mem_strip_copy_rop_dev. This new function handles the actual copy in +device space, leaving the original to cope with fiddling the rop according +to colors. + +This 'inner' function is moved to gdevm1.c so it is present in both gs +and ghostpcl builds. The existing (bitrotted) code in gdevm1.c to +'USE_COPY_ROP' is revamped to call mem_strip_copy_rop_dev, but is disabled +currently as the cluster is showing a few differences that need to be +tracked down. + +Also, this introduces new code to do gsroprun's using code in a generic +header file that gets repeatedly #included with different options. This +code is currently disabled until we can verify that it gives identical +results. The new 'templated' code uses native ints where possible, and +(in initial limited testing) seems to perform better than copy_mono. + +No cluster differences expected. + +</pre> +<p>[base/gdevmem.h base/lib.mak base/gsroprun.c base/gdevm1.c base/gsropt.h base/gsroprun1.h base/gdevmr1.c]</p> +</blockquote> + +<p><strong><a name="2011-02-19T070113.923016Z"></a> +2011-02-19T07:01:13.923016Z Alex Cherepanov</strong></p> +<blockquote> +<pre> +Add a missing check for null value during PDF resource enumeration. +Bug 691892, customer 532. +</pre> +<p>[Resource/Init/pdf_main.ps]</p> +</blockquote> + +<p><strong><a name="2011-02-18T132259.764503Z"></a> +2011-02-18T13:22:59.764503Z Robin Watts</strong></p> +<blockquote> +<pre> +Committing fix for Bug 689031 submitted by Shailesh Mistry under the +bug bounty program. Tests out fine (1 minor difference, looks like a +progression to me). + +See bug for full discussion, but basically this removes a few calls to +path_position_valid in exchange for accessing the equivalent data kept +locally. + + +</pre> +<p>[base/gxchar.c base/gzpath.h base/gxccache.c base/gspath1.c]</p> +</blockquote> + +<p><strong><a name="2011-02-18T115125.345393Z"></a> +2011-02-18T11:51:25.345393Z Ken Sharp</strong></p> +<blockquote> +<pre> +Enhancement (pdfwrite) : performance improvement + +Bug #691946 "Conversion to PDF becomes slower and slower" + +There are many places where pdfwrite compares composite objects for equality. This can +be a very slow process, depending on the nature of the object, and becomes progressively +slower as more object are added to storage. + +Previously we had added a MD5 hash to the stream data of a cos_stream in order to +improve the performance when checking fonts for equality, this change takes the whole +process much further. We now store an MD5 'fingerprint' for each composite object, +initially this is not computed and is marked as not valid. + +Whenever an equality test takes place we check to see if the composite object has an MD5 +hash calculated, and if it does, we compare the MD5 hashes. If it does not then we +compute an MD5 hash, store it, and mark it as valid. Note that for cos_stream types +we store *two* hashes, one for the dictionary and one for the stream data. + +If we alter the contents of a composite object then we mark its MD5 hash as invalid so +that we recompute it on the next occurence. Technically there could be a problem if +a composite object contains a composite object, and the descendant object is altered +after the MD5 hash is calculated for the parent. However this should not occur given +the way these structures are used (these are pdfwrite internal structures, *not* PS or +PDF objects available to the interpreter). + +This very significantly improves performance on some files, the test file for bug +#691946 takes 2642 seconds without this change (and DetectDuplicateImages true) while +it takes 963 seconds after this change. + +Note that this change depends on revision 12169 and should ideally be used with +revisions 12168 to 12171 inclusive. + +No other differences expected. +</pre> +<p>[base/gdevpdfo.c base/gdevpdfo.h]</p> +</blockquote> + +<p><strong><a name="2011-02-18T113756.561896Z"></a> +2011-02-18T11:37:56.561896Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix (pdfwrite) : images being scaled incorrectly + +Found while dealing with other problems. pdfwrite uses the image 'height' (rendered +height) and number of lines of data to calculate a 'scale' which it then applies to +the current Transformation Matrix in order to calculate an image matrix. + +However, when an image was detected as a duplicate, the scale factor was calculated +from the first image's dimensions, and then applied to the CTM for the second matrix. + +This did not appear to cause problems for PostScript and PDF but causes serious bugs +in a number of PCL files, and was clearly incorrect. We now save and restore the +height and width when substituting images to prevent this problem + +</pre> +<p>[base/gdevpdfj.c]</p> +</blockquote> + +<p><strong><a name="2011-02-18T113207.033929Z"></a> +2011-02-18T11:32:07.033929Z Ken Sharp</strong></p> +<blockquote> +<pre> +enhancement (pdfwrite) : Allow duplication image detection to be disabled + +pdfwrite tests every (non-inline) image against every other stored image to see if it is +a duplicate, and if so does not embed the duplicate in the output but simply references +the original. + +This can be slow for files with many images (each stored image must be checked when a +new image is encountered) and may be of limited benefit. + +The new flag DetectDuplicateImages (default true) can be used to enable or disable +this behaviour + +No differences expected +</pre> +<p>[base/gdevpdfj.c base/gdevpdfx.h base/gdevpdfp.c doc/Ps2pdf.htm base/gdevpdfb.h]</p> +</blockquote> + +<p><strong><a name="2011-02-18T112524.853829Z"></a> +2011-02-18T11:25:24.853829Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix (pdfwrite) : Correction to an equality test + +This fixes a long-standing bug when checking the equality of patterns. + +We need to ensure when substituting patterns that neither of the patterns is already +substituted. But the code only tested one of the patterns (and was a duplicate of +another test), which led to incorrect results. This should always have been a problem +but for some reason seems to have been masked in previous releases. New code for +testing equality of composite objects revealed the problem. + +No differences expected, as the problem is only revealed with code which follows in a +subsequent commit. +</pre> +<p>[base/gdevpdfi.c]</p> +</blockquote> + +<p><strong><a name="2011-02-18T111523.457563Z"></a> +2011-02-18T11:15:23.457563Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix a typo in an enumerated type. No differences expected. +</pre> +<p>[base/gxhldevc.h base/gxhldevc.c base/gdevpdfg.c]</p> +</blockquote> + +<p><strong><a name="2011-02-15T163659.934186Z"></a> +2011-02-15T16:36:59.934186Z Henry Stiles</strong></p> +<blockquote> +<pre> +Double the allowed space for cached chars and increase the maximum +byte size of a single glyph that can be cached. +</pre> +<p>[base/gsfont.c]</p> +</blockquote> + +<p><strong><a name="2011-02-15T150755.282721Z"></a> +2011-02-15T15:07:55.282721Z Ray Johnston</strong></p> +<blockquote> +<pre> +Fix for building the gs***w64.exe self extracting installer compatible with +the new 64-bit binary naming and makefile macro (BUILD_SYSTEM) +</pre> +<p>[psi/winint.mak]</p> +</blockquote> + +<p><strong><a name="2011-02-15T092128.927211Z"></a> +2011-02-15T09:21:28.927211Z Chris Liddell</strong></p> +<blockquote> +<pre> +Ensure that the OpenPrinting drivers get removed from the drivers list +if iconv/libiconv are not available. + +The strings used to identify the drivers in the list were incorrect. + +</pre> +<p>[base/configure.ac]</p> +</blockquote> + +<p><strong><a name="2011-02-14T203933.924424Z"></a> +2011-02-14T20:39:33.924424Z Robin Watts</strong></p> +<blockquote> +<pre> +Fix Bug 691917. In revision 11146 I made op_array_table_global and +op_array_table_local be elements of the context rather than being +globals, and changed all the code to access these elements through +the context. + +Unfortunately I forgot to cope with when new contexts are generated by +forking execution. The correct fix is, I believe to simply copy the +op_table pointers over to the new context. This has been done here, and +seems to solve the reported bug. + +No cluster differences expected. + +</pre> +<p>[psi/zcontext.c]</p> +</blockquote> + +<p><strong><a name="2011-02-14T110439.509187Z"></a> +2011-02-14T11:04:39.509187Z Till Kamppeter</strong></p> +<blockquote> +<pre> +Removed a tab accidentally introduced in rev 12082. +</pre> +<p>[Resource/Init/cidfmap]</p> +</blockquote> + +<p><strong><a name="2011-02-10T171423.128533Z"></a> +2011-02-10T17:14:23.128533Z Chris Liddell</strong></p> +<blockquote> +<pre> +Ensure that a --build option is propogated to the other +configure scripts we call. + +</pre> +<p>[base/configure.ac]</p> +</blockquote> + +<p><strong><a name="2011-02-10T132158.493309Z"></a> +2011-02-10T13:21:58.493309Z Ken Sharp</strong></p> +<blockquote> +<pre> +fix error in revision 12140 + +When fetching the size of the stream for a /Indexed colour space, omitted to check if the +/Length of the stream was an indirect object. Now dereference the object if this is the +case. + +Should fix the 14 files with errors introduced in 12140. +</pre> +<p>[Resource/Init/pdf_draw.ps]</p> +</blockquote> + +<p><strong><a name="2011-02-10T104326.255155Z"></a> +2011-02-10T10:43:26.255155Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix : colour space handling bug and improved handling of broken ICC space + +Bug #691941 "Interpretation of PDF aborts with /typecheck" + +The PDF file in the specimen contains an invalid colour space of the form: + +/Indexed [/ICCBased <</N 1 /Alternate [/Indexed /DeviceRGB 255 7 0 R]>>] 255 7 0 R] + +The number of components in the ICCBased specification is incorrect, as the profile has +3 channels. This was not detected previously. Falling back to the /Alternate we see +that we have a /Indexed space depending on a /Indexed space which is also invalid, but +we choose to ignore this. + +There was also a bug in the colour space handling for ICCbased spaces which caused a +typecheck if the alternate space was a /Indexed space. + +Finally, the PDF interpreter is updated so that when given a stream as the data source +for a /Indexed space it reads and returns a string which is the greater of the declared +size of the stream, or the calculated size required, given the number of components. +Previously we always returned the calculated size, which was too little in this case +as the number of components in the ICCBased space is incorrect. + +With these changes the (invalid) specimen file runs to completion. + +No differences expected. +</pre> +<p>[psi/zcolor.c psi/zicc.c Resource/Init/pdf_draw.ps]</p> +</blockquote> + +<p><strong><a name="2011-02-10T103323.506445Z"></a> +2011-02-10T10:33:23.506445Z Ken Sharp</strong></p> +<blockquote> +<pre> +Fix Bug #691918 + +Update the Unicode decodings applied to TrueType fonts to match the latest Adobe glyph +list. Fixes some problems with incorrect mappings and adds numerous new mappings. A +similar but less extensive change is made to the FCO_Unicode mappings as well. + +Thanks to SaGS for the work on this problem. + +No differences expected as these are only used for ToUnicode CMaps.</pre> +<p>[Resource/Decoding/Unicode Resource/Decoding/FCO_Unicode]</p> +</blockquote> + + <h2><a name="Version9.01"></a>Version 9.01 (2011-02-07)</h3> @@ -13028,7 +15050,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Install.htm b/gs/doc/Install.htm index c1a7cb3de..251cc0dbb 100644 --- a/gs/doc/Install.htm +++ b/gs/doc/Install.htm @@ -546,7 +546,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Issues.htm b/gs/doc/Issues.htm index 2abdf1084..5565b079f 100644 --- a/gs/doc/Issues.htm +++ b/gs/doc/Issues.htm @@ -588,7 +588,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Language.htm b/gs/doc/Language.htm index d076994ee..9d3fc09d7 100644 --- a/gs/doc/Language.htm +++ b/gs/doc/Language.htm @@ -2367,7 +2367,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Lib.htm b/gs/doc/Lib.htm index 2c49c27af..87037c2d9 100644 --- a/gs/doc/Lib.htm +++ b/gs/doc/Lib.htm @@ -861,7 +861,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Make.htm b/gs/doc/Make.htm index 3b6d14523..a5445bcb3 100644 --- a/gs/doc/Make.htm +++ b/gs/doc/Make.htm @@ -2878,7 +2878,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/News.htm b/gs/doc/News.htm index 1cfcbdd94..14b5e140d 100644 --- a/gs/doc/News.htm +++ b/gs/doc/News.htm @@ -56,43 +56,36 @@ overview</a>. <!-- [2.0 begin contents] ================================================== --> -<h2><a name="Version9.01"></a>Version 9.01 (2011-02-07)</h3> +<h2><a name="Version9.02"></a>Version 9.02 (2011-03-28)</h3> -<p>This is the second release in the stable 9.x series. +<p>This is the third release in the stable 9.x series. -<p> Highlights in this release include: - -<p> A new, robust CFF parser implemented in C (replacing the previous -Poscript one), - -<p> tiffscaled device - this renders internally as tiffgray, but then -downsamples by an integer scale factor (specified by -dDownScaleFactor=n) -and error diffuses to 1bpp output. The tiffscaled device also implements -limited minimum feature size functionality; by setting -dMinFeatureSize -to 1, 2 or 3, the device output is guaranteed to generate minimum dot -sizes as multiples of the final resolution, useful for devices that -offer finer position control than dot size control. +<p>This a an "out of order" release, primarily to ensure the +GPL Ghostscript release remains in version "lock-step" with the +Artifex commercial release. -<p> Add DSC compatible output in ps2write. - -<p> Windows makefiles now support 64 bit builds on 64 bit systems. - -<p> A number of performance, memory use, and stability improvements with the new -features introduced in 9.00, plus the usual bug fixes. +<p> Highlights in this release include: -<p> We have also dropped support for Watcom and Borland development environments. -These had not been maintained for some time, and were suffering "bit rot". +<p>For monochrome devices, there is a new halftone technique for sampled +image data. The existing technique is very efficient (and is is still used) +for large areas of color, such as an area fill, but encountered performance +problems dealing with sampled image data where a given colour value only +covered a few pixels at a time. The new approach applies the halftone threshold +array directly to the image samples. +<p> Further performance, memory use, and stability improvements with the new +features introduced in 9.00, as well as Unix/Linux build fixes, plus the usual +assorted bug fixes. <p>For a list of open issues, or to report problems, please visit <a href="http://bugs.ghostscript.com/">bugs.ghostscript.com</a>. -<h3><a name="9.01_Incompatible_changes"></a>Incompatible changes</h3> +<h3><a name="9.02_Incompatible_changes"></a>Incompatible changes</h3> <p> No recorded incompatible changes. -<h3><a name="9.01_changelog"></a>Changelog</h3> +<h3><a name="9.02_changelog"></a>Changelog</h3> <p>See the <a href="History9.htm">history file</a> for complete log of changes. @@ -117,7 +110,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Projects.htm b/gs/doc/Projects.htm index a0120d84b..3378286ba 100644 --- a/gs/doc/Projects.htm +++ b/gs/doc/Projects.htm @@ -669,7 +669,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Ps-style.htm b/gs/doc/Ps-style.htm index 253c00ec5..cfdd8ee06 100644 --- a/gs/doc/Ps-style.htm +++ b/gs/doc/Ps-style.htm @@ -505,7 +505,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Ps2epsi.htm b/gs/doc/Ps2epsi.htm index 2f2cedcef..1d04a5909 100644 --- a/gs/doc/Ps2epsi.htm +++ b/gs/doc/Ps2epsi.htm @@ -176,7 +176,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Ps2pdf.htm b/gs/doc/Ps2pdf.htm index b99db0efd..55f5a19be 100644 --- a/gs/doc/Ps2pdf.htm +++ b/gs/doc/Ps2pdf.htm @@ -1081,7 +1081,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Ps2ps2.htm b/gs/doc/Ps2ps2.htm index 99fb7acd4..0bcb9f97b 100644 --- a/gs/doc/Ps2ps2.htm +++ b/gs/doc/Ps2ps2.htm @@ -276,7 +276,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Psfiles.htm b/gs/doc/Psfiles.htm index 6c27bc035..98e41172b 100644 --- a/gs/doc/Psfiles.htm +++ b/gs/doc/Psfiles.htm @@ -1017,7 +1017,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Readme.htm b/gs/doc/Readme.htm index ac716aaa2..61523428b 100644 --- a/gs/doc/Readme.htm +++ b/gs/doc/Readme.htm @@ -581,7 +581,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Release.htm b/gs/doc/Release.htm index 3028e289d..38f157f0e 100644 --- a/gs/doc/Release.htm +++ b/gs/doc/Release.htm @@ -844,7 +844,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Source.htm b/gs/doc/Source.htm index 0e3e3d215..930a0e8c6 100644 --- a/gs/doc/Source.htm +++ b/gs/doc/Source.htm @@ -376,7 +376,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Unix-lpr.htm b/gs/doc/Unix-lpr.htm index 969964993..7e1760437 100644 --- a/gs/doc/Unix-lpr.htm +++ b/gs/doc/Unix-lpr.htm @@ -260,7 +260,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Use.htm b/gs/doc/Use.htm index 69217d17b..f041a8b5b 100644 --- a/gs/doc/Use.htm +++ b/gs/doc/Use.htm @@ -3854,7 +3854,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/Xfonts.htm b/gs/doc/Xfonts.htm index aec831fed..77d21962c 100644 --- a/gs/doc/Xfonts.htm +++ b/gs/doc/Xfonts.htm @@ -268,7 +268,7 @@ or contact Artifex Software, Inc., 7 Mt. Lassen Drive - Suite A-134, San Rafael, CA 94903, U.S.A., +1(415)492-9861, for further information. <p> -<small>Ghostscript version 9.01, 7 February 2011 +<small>Ghostscript version 9.02, 28 March 2011 <!-- [3.0 end visible trailer] ============================================= --> diff --git a/gs/doc/gs-vms.hlp b/gs/doc/gs-vms.hlp index c5bdf7383..a20977bb9 100644 --- a/gs/doc/gs-vms.hlp +++ b/gs/doc/gs-vms.hlp @@ -1,7 +1,7 @@ 1 gs gs - GPL Ghostscript interpreter/previewer ! $Id$ -! Ghostscript version 9.01, 7 February 2011 +! Ghostscript version 9.02, 28 March 2011 Usage: $ gs [options] [file ...] diff --git a/gs/man/dvipdf.1 b/gs/man/dvipdf.1 index c6a7a1f48..8002da14f 100644 --- a/gs/man/dvipdf.1 +++ b/gs/man/dvipdf.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH DVIPDF 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH DVIPDF 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME dvipdf \- Convert TeX DVI file to PDF using ghostscript and dvips .SH SYNOPSIS @@ -22,7 +22,7 @@ and any options from the command-line. .SH SEE ALSO gs(1), dvips(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/font2c.1 b/gs/man/font2c.1 index a49de060c..acbcb9cd5 100644 --- a/gs/man/font2c.1 +++ b/gs/man/font2c.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH FONT2C 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH FONT2C 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME font2c \- Write PostScript Type 0 or Type 1 font as C code .SH SYNOPSIS @@ -18,7 +18,7 @@ that can be linked with the interpreter. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/gs.1 b/gs/man/gs.1 index e412d4cbb..cc717fdc4 100644 --- a/gs/man/gs.1 +++ b/gs/man/gs.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH GS 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH GS 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME gs \- Ghostscript (PostScript and PDF language interpreter and previewer) .SH SYNOPSIS @@ -404,7 +404,7 @@ The various Ghostscript document files (above), especially \fBUse.htm\fR. See http://bugs.ghostscript.com/ and the Usenet news group comp.lang.postscript. .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/gslp.1 b/gs/man/gslp.1 index 458e6c3d8..4f133625d 100644 --- a/gs/man/gslp.1 +++ b/gs/man/gslp.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH GSLP 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH GSLP 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME gslp \- Format and print text using ghostscript .br @@ -93,7 +93,7 @@ Also, the string %# in a heading or footing is replaced with the page #. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/gsnd.1 b/gs/man/gsnd.1 index 12a01546a..ce9f7e4aa 100644 --- a/gs/man/gsnd.1 +++ b/gs/man/gsnd.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH GSND 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH GSND 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME gsnd \- Run ghostscript (PostScript and PDF engine) without display .SH SYNOPSIS @@ -13,7 +13,7 @@ flag, followed by any other arguments from the command-line. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/pdf2dsc.1 b/gs/man/pdf2dsc.1 index 593caa6c7..8324905f5 100644 --- a/gs/man/pdf2dsc.1 +++ b/gs/man/pdf2dsc.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PDF2DSC 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PDF2DSC 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME pdf2dsc \- generate a PostScript page list of a PDF document .SH SYNOPSIS @@ -29,6 +29,6 @@ Ghostscript since release 3.53. .SH SEE ALSO gs(1), ghostview(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Yves Arrouye <yves.arrouye@usa.net> and Russell Lang gsview at ghostgum.com.au diff --git a/gs/man/pdf2ps.1 b/gs/man/pdf2ps.1 index 364fa0d76..ecbe6f772 100644 --- a/gs/man/pdf2ps.1 +++ b/gs/man/pdf2ps.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PDF2PS 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PDF2PS 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME pdf2ps \- Ghostscript PDF to PostScript translator .SH SYNOPSIS @@ -15,7 +15,7 @@ LanguageLevel 3 in the output. Run "\fBgs -h\fR" to find the location of Ghostscript documentation on your system, from which you can get more details. .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/pdfopt.1 b/gs/man/pdfopt.1 index d6379bcae..11ed43c00 100644 --- a/gs/man/pdfopt.1 +++ b/gs/man/pdfopt.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PDFOPT 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PDFOPT 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME pdfopt \- Ghostscript PDF Optimizer .SH SYNOPSIS @@ -21,7 +21,7 @@ system, from which you can get more details. "Linearized PDF" in Adobe's PDF reference manual, http://partners.adobe.com/asn/developer/acrosdk/DOCS/pdfspec.pdf .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/pf2afm.1 b/gs/man/pf2afm.1 index 6455f87a9..8635fd710 100644 --- a/gs/man/pf2afm.1 +++ b/gs/man/pf2afm.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PF2AFM 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH PF2AFM 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME pf2afm \- Make an AFM file from Postscript (PFB/PFA/PFM) font files using ghostscript .SH SYNOPSIS @@ -16,7 +16,7 @@ gs(1) .br pf2afm.ps in the Ghostscript lib directory. .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/pfbtopfa.1 b/gs/man/pfbtopfa.1 index 9a5204d19..f82a1e7d9 100644 --- a/gs/man/pfbtopfa.1 +++ b/gs/man/pfbtopfa.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PFBTOPFA 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH PFBTOPFA 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME pfbtopfa \- Convert Postscript .pfb fonts to .pfa format using ghostscript .SH SYNOPSIS @@ -11,7 +11,7 @@ to convert a .pfb file into a .pfa file. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/printafm.1 b/gs/man/printafm.1 index 162f035cd..993948fb3 100644 --- a/gs/man/printafm.1 +++ b/gs/man/printafm.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PRINTAFM 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH PRINTAFM 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME printafm \- Print the metrics from a Postscript font in AFM format using ghostscript .SH SYNOPSIS @@ -12,7 +12,7 @@ Output goes to stdout. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/ps2ascii.1 b/gs/man/ps2ascii.1 index adb8086f3..be18f2b1c 100644 --- a/gs/man/ps2ascii.1 +++ b/gs/man/ps2ascii.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PS2ASCII 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PS2ASCII 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME ps2ascii \- Ghostscript translator from PostScript or PDF to ASCII .SH SYNOPSIS @@ -23,7 +23,7 @@ system, from which you can get more details. .SH SEE ALSO pstotext(1), http://www.research.digital.com/SRC/virtualpaper/pstotext.html .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/ps2epsi.1 b/gs/man/ps2epsi.1 index 4c1c2cc41..f209578d9 100644 --- a/gs/man/ps2epsi.1 +++ b/gs/man/ps2epsi.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PS2EPSI 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PS2EPSI 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME ps2epsi \- generate conforming Encapsulated PostScript .SH SYNOPSIS @@ -60,7 +60,7 @@ ps2epsi.ps>the Ghostscript program which does the work .SH SEE ALSO gs (1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. However, the content may be obsolete, or inconsistent with ps2epsi.txt. .SH AUTHOR George Cameron diff --git a/gs/man/ps2pdf.1 b/gs/man/ps2pdf.1 index f8cc26a4f..24b21f566 100644 --- a/gs/man/ps2pdf.1 +++ b/gs/man/ps2pdf.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PS2PDF 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH PS2PDF 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME ps2pdf \- Convert PostScript to PDF using ghostscript .br @@ -89,7 +89,7 @@ Ps2pdf.htm in the Ghostscript documentation See http://bugs.ghostscript.com/ and the Usenet news group comp.lang.postscript. .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/ps2pdfwr.1 b/gs/man/ps2pdfwr.1 index b46f95518..5e2ba74cb 100644 --- a/gs/man/ps2pdfwr.1 +++ b/gs/man/ps2pdfwr.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PS2PDFWR 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH PS2PDFWR 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME ps2pdfwr \- Convert PostScript to PDF without specifying CompatibilityLevel, using ghostscript .SH SYNOPSIS @@ -24,7 +24,7 @@ scripts all invoke this one with the addition of the respective compatibility le .SH SEE ALSO gs(1), ps2pdf(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/ps2ps.1 b/gs/man/ps2ps.1 index 9f13d7d4d..e988090ca 100644 --- a/gs/man/ps2ps.1 +++ b/gs/man/ps2ps.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH PS2PS 1 "7 February 2011" 9.01 "Ghostscript Tools" \" -*- nroff -*- +.TH PS2PS 1 "28 March 2011" 9.02 "Ghostscript Tools" \" -*- nroff -*- .SH NAME ps2ps, eps2eps \- Ghostscript PostScript "distiller" .SH SYNOPSIS @@ -27,7 +27,7 @@ lower level output than is desirable. Use with caution. .SH SEE ALSO ps2pdf(1), ps2ascii(1), ps2epsi(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. diff --git a/gs/man/wftopfa.1 b/gs/man/wftopfa.1 index b1794479a..1c0f492ef 100644 --- a/gs/man/wftopfa.1 +++ b/gs/man/wftopfa.1 @@ -1,5 +1,5 @@ .\" $Id$ -.TH WFTOPFA 1 "7 February 2011" 9.01 Ghostscript \" -*- nroff -*- +.TH WFTOPFA 1 "28 March 2011" 9.02 Ghostscript \" -*- nroff -*- .SH NAME wftopfa \- Convert a Wadalab base font to Postscript .PFA (or .PFB) format using ghostscript @@ -13,7 +13,7 @@ format. .SH SEE ALSO gs(1) .SH VERSION -This document was last revised for Ghostscript version 9.01. +This document was last revised for Ghostscript version 9.02. .SH AUTHOR Artifex Software, Inc. are the primary maintainers of Ghostscript. |