2011-02-07T14:10:27.833602Z Chris Liddell

>     Some updates to the details of the UFST and Freetype related
>     information.

>     Plus adding the warning about Xfonts pending removal.

> [doc/Make.htm doc/Xfonts.htm]

2011-02-05T15:29:32.296497Z Chris Liddell

>     As we plan to deprecate Xfonts in a future release, add a
>     warning message to this effect when an Xfont is used, as follows:

>     "Warning: the Xfonts feature is deprecated and will be removed in a future release."

>     No cluster differences expected.

> [base/gxccman.c]

2011-02-05T15:27:25.033646Z Chris Liddell

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

> [base/gdevbit.c]

2011-02-04T15:51:42.379449Z Robin Watts

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

>     No cluster changes expected.

> [base/gsroprun.c]

2011-02-03T12:30:28.178697Z Chris Liddell

>     A final tweak to the FAPI/UFST code to keep C compilers
>     less liberal than gcc happy (specifically Visual C).

>     No functional changes.

> [psi/fapiufst.c]

2011-02-02T18:27:57.905008Z Chris Liddell

>     A couple of minor UFST related tweaks to account for differences between
>     UFST 6.2 and UFST 5.x.

> [psi/fapiufst.c base/gxfapiu.c]

2011-02-02T17:18:09.939035Z Ray Johnston

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

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

2011-02-02T15:34:53.024741Z Ken Sharp

>     Remove 4 cases where lines had apparently spurious leading spaces, this seriously
>     confused nmake and refused to build on Windows.

>     No cluster differences expected.

> [psi/msvc32.mak]

2011-02-02T15:14:53.428205Z Ken Sharp

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

> [base/gdevpdfu.c]

2011-02-02T14:55:37.673202Z Robin Watts

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

> [ghostscript.vcproj]

2011-02-02T14:12:15.676565Z Chris Liddell

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

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

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

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

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

2011-02-02T13:30:54.074131Z Ken Sharp

>     The ps2write dependency on the new header files was incorrect (over-enthusiastic
>     copy and paste error)

> [base/devs.mak]

2011-02-02T11:23:07.465859Z Chris Liddell

>     Allow building with the system (shared) lcms library.

>     Bug 691644.

> [base/lib.mak base/Makefile.in base/configure.ac]

2011-02-02T09:28:15.868989Z Ken Sharp

>     Remove the check on opdfread.ps from gs_pdfwr.ps as this is no longer shipped as a
>     PostScript file in /gs/Resource

> [Resource/Init/gs_pdfwr.ps]

2011-02-02T08:46:11.323868Z Ken Sharp

>     Update two make files that had dependencies on opdfread.ps, which has been removed from
>     the PostScript file system.

> [psi/psromfs.mak base/unixinst.mak]

2011-02-02T08:27:43.587977Z Ken Sharp

>     It seems that three of the files removed in revision 12093 are used by devices other
>     than ps2write. Replacing those files.

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

2011-02-02T08:14:36.361918Z Ken Sharp

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

>     No differences expected.

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

2011-02-01T22:11:44.446124Z Marcos H. Woehrmann

>     Fix for missing arch.h when compiling gdevcups.c with parallel make.

> [base/devs.mak]

2011-02-01T21:46:27.115736Z Ray Johnston

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

> [Resource/Init/pdf_draw.ps]

2011-02-01T17:07:50.035956Z Chris Liddell

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

> [psi/fapi_ft.c]

2011-02-01T14:00:46.378487Z Ken Sharp

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

>     It is possible that the ToUnicode CMap is incorrectly generated, but this is no worse
>     than having no CMap at all.

>     No expected differences since ToUnicode CMaps are not used in rendering.

> [base/gdevpdtw.c]

2011-02-01T11:57:26.132691Z Robin Watts

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

>     No cluster differences expected or shown in testing.

> [/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]

2011-02-01T08:34:27.091701Z Ken Sharp

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

> [base/gdevpdtd.c]

2011-01-31T18:10:10.028647Z Robin Watts

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

>     Both versions are disabled by default until the case for their existence has
>     been proven, but are committed here to avoid bitrot.

>     No cluster differences expected, as the default code does not change.

> [base/scf.h]

2011-01-31T12:32:10.322306Z Robin Watts

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

>     No cluster differences expected.

> [base/gdevpbm.c]

2011-01-31T11:19:53.283257Z Ken Sharp

>     Revert minor changes accidentally committed in revision 12082.

> [Resource/Init/Fontmap.GS Resource/Init/cidfmap lib/PDFA_def.ps]

2011-01-31T11:15:05.175916Z Ken Sharp

>     Add the two new make files required for the altered CUPS build, these were accidentally
>     omitted in revision 12080.

> [Resource/Init/Fontmap.GS base/lcups.mak Resource/Init/cidfmap lib/PDFA_def.ps base/lcupsi.mak]

2011-01-31T11:09:11.349638Z Ken Sharp

>     Undo changes to PDFX_def.ps accidentally committed as part of the CPS changes.

> [lib/PDFX_def.ps]

2011-01-31T11:06:11.139867Z Ken Sharp

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

>     On Windows CUPS is now always built and installed. On Unix systems the behavious is as
>     follows:

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

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

2011-01-29T15:35:32.332503Z Ken Sharp

>     More changes to the CUPS sources so they will compile on various systems:

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

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

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

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

>     No differences expected as this code is not yet in use.

> [cups/libs/cups/localize.c cups/libs/cups/language.c cups/libs/cups/ppd.c]

2011-01-28T13:21:20.983748Z Robin Watts

>     Further rop run optimisations.

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

>     Cluster pushing shows no differences.

> [base/gsroprun.c]

2011-01-28T12:27:37.269985Z Robin Watts

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

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

>     Clusterpush shows no changes.

> [base/gdevm8.c]

2011-01-27T14:33:46.308935Z Ken Sharp

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

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

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

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

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

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

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

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

2011-01-27T13:07:15.912561Z Tor Andersson

>     Relax version check in JPEG-XR to allow older version HDP and WDP images.

> [jpegxr/cr_parse.c]

2011-01-26T18:10:28.996727Z Chris Liddell

>     Fix the message for the new IJS check to read IJS, instead of jpeg!

> [base/configure.ac]

2011-01-26T14:51:40.178552Z Chris Liddell

>     revert accidentally committed file.

> [base/jpeg.mak]

2011-01-26T12:25:36.497890Z Chris Liddell

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

>     Bug 691904

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

2011-01-26T01:04:40.273776Z Alex Cherepanov

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

> [Resource/Init/gs_ttf.ps]

2011-01-25T12:03:22.384476Z Ken Sharp

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

>     No differences expected.

> [cups/gdevcups.c]

2011-01-24T23:51:39.084611Z Tor Andersson

>     Add JPEG-XR makefile and library to XPS build.

> [/trunk/ghostpdl/xps/xps.mak /trunk/ghostpdl/xps/xps_msvc.mak base/jpegxr.mak /trunk/ghostpdl/xps/xps_gcc.mak]

2011-01-24T23:51:23.771340Z Tor Andersson

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

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

2011-01-24T18:16:40.240500Z Robin Watts

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

> [base/gdevmpla.c]

2011-01-24T14:56:30.755196Z Chris Liddell

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

>     Reorganise and correct the names of the devices specified in
>     configure.ac so that the options --with-drivers=[FILES,PRINTERS,X11]
>     actually work.

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

> [base/Makefile.in base/configure.ac]

2011-01-20T04:23:02.586888Z Alex Cherepanov

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

> [Resource/Init/pdf_rbld.ps]

2011-01-19T20:25:54.918598Z Robin Watts

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

> [base/gdevp14.c base/gstrans.c]

2011-01-19T18:00:59.394482Z Robin Watts

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

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

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

> [base/gdevp14.c base/gstrans.c base/gstparam.h]

2011-01-18T21:52:56.712015Z regression

>     Temporarily add 75 dpi pgmraw output to GhostPCL and disable ps2write output to the cluster regressions.

> [toolbin/localcluster/build.pl]

2011-01-18T10:22:12.280482Z Chris Liddell

>     Resolve some problems with the shared library build on Sparc/Solaris,
>     with the SunStudio tools.

>     Have configure select between the GNUism -soname and the more convetional
>     -h option to set the "internal" name of the shared library.

>     SunStudio 12 has changed the default optimization level option for cc to
>     be -O3 (previously was -02), which results in Ghostscript crashing.

>     No cluster differences expected.

>     Bug 689490

> [base/macosx.mak base/Makefile.in base/configure.ac base/unix-dll.mak base/unix-gcc.mak base/macos-mcp.mak]

2011-01-17T21:37:08.425154Z Alex Cherepanov

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

> [psi/msvc32.mak]

2011-01-17T17:33:50.118892Z Robin Watts

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

> [base/gdevmr8n.c base/gsroprun.c base/gsropt.h]

2011-01-17T12:11:39.376205Z Robin Watts

>     Remove unused lop_ral definitions, and move pdf14 lop bit down into the freed
>     space (for neatness).

>     No changes expected in cluster.

> [base/gsropt.h]

2011-01-16T01:25:36.175335Z Marcos H. Woehrmann

>     Added missing std.h dependency to gstoptab.c to fix parallel make
>     under linux.

> [base/lib.mak]

2011-01-15T16:01:30.937666Z Robin Watts

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

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

> [base/lib.mak base/gsroprun.c base/gsropt.h base/gdevmr1.c]

2011-01-15T15:53:50.166886Z Robin Watts

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

> [base/gsropt.h]

2011-01-14T18:58:46.405071Z Henry Stiles

>     Bracket off gs_debug_c with #ifdef DEBUG so it is not called in
>     production builds.

> [base/gxht.c base/gxclimag.c base/gxttfb.c base/gxpcmap.c base/gxccman.c base/gsfcmap1.c base/gspaint.c]

2011-01-14T16:56:47.376046Z Chris Liddell

>     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

> [base/lib.mak contrib/gomni.c base/Makefile.in base/configure.ac base/devs.mak]

2011-01-13T16:19:39.522851Z Chris Liddell

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

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

2011-01-13T14:37:33.986698Z Robin Watts

>     Fix Bug 689698 by prefixing scan_token (and other externally exported
>     scanning related symbols) by gs_.

>     No changes in cluster testing (other than 1 timeout, and 2 indeterminisms).

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

2011-01-12T21:11:53.461044Z Robin Watts

>     Fix Bug 691682 - cryptic error messages when misspecifying compression type
>     for tiff devices.

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

>     Also, we output a more helpful error message in the case where the
>     compression type is misselected.

>     Cluster testing shows no changes.

> [base/gdevtifs.c]

2011-01-11T21:33:54.972732Z Michael Vrhel

>     Fix for a number of issues found by Ray with the halftone creation tool.

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

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

> [toolbin/color/halftone/halfttoning/halfttoning.vcproj toolbin/color/halftone/README toolbin/color/halftone/halfttoning/halftone.c]

2011-01-11T01:17:59.815496Z Ray Johnston

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

> [toolbin/color/halftone/halfttoning/halftone.c]

2011-01-11T00:49:20.559732Z Michael Vrhel

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

> [base/gxicolor.c]

2011-01-10T22:00:19.847574Z Till Kamppeter

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

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

2011-01-10T03:29:52.464842Z Alex Cherepanov

>     Add support for MSVC 10 to msvc32.mak .

> [psi/msvc32.mak]

2011-01-09T02:19:19.656942Z Michael Vrhel

>     Fix for color related warnings in bug 691459

> [base/gxi12bit.c base/lib.mak base/gxiscale.c base/gsicc_manage.c base/gxcmap.h base/gxicolor.c base/gscspace.c]

2011-01-08T19:56:51.307278Z Alex Cherepanov

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

> [Resource/Init/pdf_font.ps]

2011-01-08T19:42:31.743686Z regression

>     Additional changes to support ps2write in the cluster (and nightly and weekly) regression.

> [toolbin/localcluster/clustermaster.pl toolbin/localcluster/readlog.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl toolbin/localcluster/compare.pl]

2011-01-08T17:56:07.987718Z regression

>     Add ps2write testing to the cluster regression.

> [toolbin/localcluster/build.pl]

2011-01-08T17:55:26.179279Z Alex Cherepanov

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

> [Resource/Init/pdf_font.ps]

2011-01-08T10:50:04.294111Z Till Kamppeter

>     Fixed typo.

> [cups/gdevcups.c]

2011-01-08T10:47:12.179146Z Till Kamppeter

>     CUPS Raster device: Some clean-up.

> [cups/gdevcups.c]

2011-01-08T10:36:56.827100Z Till Kamppeter

>     CUPS Raster: Another approach to fix both bug #691733 and #690435: Set _old values at the beginning of the cups_put_params() function.

> [cups/gdevcups.c]

2011-01-07T23:33:17.663910Z Till Kamppeter

>     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

>     WEith this both bug #691733 and bug #690435 get fixed, but this is not
>     necessarily he right and best solution.

> [cups/gdevcups.c]

2011-01-07T14:05:17.614099Z Till Kamppeter

>     Fixed search-and-replace error in "cups" output device, bug 691871.

> [cups/gdevcups.c]

2011-01-07T04:49:42.455234Z Michael Vrhel

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

> [base/gxi12bit.c base/gdevp14.c base/lib.mak base/gxcmap.c base/gxiscale.c base/gdevnfwd.c base/gxcmap.h base/gxicolor.c]

2011-01-06T19:18:56.657732Z Alex Cherepanov

>     Fix a cut-ant-paste error in setting QuantTables for JPXEncode filter.
>     Bug 691868.

> [base/sdeparam.c]

2011-01-06T11:08:52.017177Z Ken Sharp

>     Minor enhancement to ps2write for DSC output, remove trailing EOF.

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

>     No differences expected.

> [base/gdevpdf.c]

2011-01-05T17:35:42.089947Z Michael Vrhel

>     Reverting of commit 11995

> [base/gxipixel.c base/lib.mak]

2011-01-05T16:05:22.763938Z Ken Sharp

>     ps2write DSC enhancement. Alter the default setting of CompressPages and CompressFonts to
>     true. Gives better conforming output at present (as well as smaller output)

> [Resource/Init/gs_pdfwr.ps]

2011-01-05T15:43:41.972063Z Ken Sharp

>     Fix three compiler warnings in revision 11997

> [base/gdevpdfu.c]

2011-01-05T15:28:39.325806Z Till Kamppeter

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

> [base/Makefile.in]

2011-01-05T14:17:41.770782Z Ken Sharp

>     ps2write DSC enhancement. Belt and braces approach when emitting a serialised array/proc

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

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

> [base/gdevpdfu.c]

2011-01-04T18:56:36.226711Z Alex Cherepanov

>     Fix spelling errors in a German man page. Thanks to Peter Dyballa for
>     the patch. Bug 691863.

> [man/de/gsnd.1]

2011-01-04T18:19:41.129921Z Michael Vrhel

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

> [base/gxipixel.c base/lib.mak]

2011-01-04T16:35:38.827232Z Ken Sharp

>     More DSC-compliant ps2write work.

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

>     No differences expected as ps2write is not currently regression tested.

> [base/gdevpdfu.c]

2011-01-04T10:48:32.930138Z Ken Sharp

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

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

>     Finally, the PDF Reference (1.7) says:

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

> [base/gsfcmap.c base/gdevpdte.c]

2011-01-03T20:19:58.048424Z Ray Johnston

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

> [base/gsmchunk.c]

2011-01-03T18:58:00.432432Z Henry Stiles

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

> [base/gdevdgbr.c]

2011-01-03T16:20:21.454447Z Henry Stiles

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

> [base/gximono.c base/gximage.h]

2011-01-03T14:33:56.098558Z Ken Sharp

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

>     No differences expected.

> [base/gdevpdtt.c]

2011-01-03T06:21:52.574265Z Alex Cherepanov

>     Adjust pdfemptycount variable during .execgroup execution to reflect the
>     actual stack count. Avoid errors in sc1/scn caused by wrong operand count.
>     Bug 691624.

> [Resource/Init/pdf_draw.ps]

2011-01-01T16:17:49.255469Z Alex Cherepanov

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

> [Resource/Init/pdf_draw.ps]

2010-12-31T06:23:59.391706Z Alex Cherepanov

>     Trap errors that may happen during loading of embedded fonts and try
>     to load the font by the name. Bug 691045.

> [Resource/Init/pdf_font.ps]

2010-12-30T19:09:59.966731Z Alex Cherepanov

>     Use -fPIC instead of -KPIC on SunOS for "so" target when compiler is gcc.
>     Bug 690630, customer 200.

> [base/configure.ac]

2010-12-30T14:11:42.974030Z Alex Cherepanov

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

> [base/gspath.h base/gxshade1.c base/gspath.c]

2010-12-29T13:01:45.722135Z Alex Cherepanov

>     Ignore transparency group XObject without /Group attribute and issue a
>     warning about it. Bug 691854.

> [Resource/Init/pdf_draw.ps]

2010-12-28T03:13:57.856572Z Alex Cherepanov

>     Implement correct defaults for /FontMatrix attribute in composite CFF
>     font following analysis by Ken and Masaki (see the comment). Bug 690724.

> [psi/zfont2.c]

2010-12-27T23:34:39.189121Z Alex Cherepanov

>     Fix unterminated string used by "%%CreationDate:" comment in ps2write
>     device. Partial fix for 691853.

> [base/gdevpdfu.c]

2010-12-24T11:08:47.918403Z Chris Liddell

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

>     This ensures that the UFST 5.x FAPI plugin can coexist
>     safely with the Freetype FAPI plugin.

> [psi/fapiufst.c]

2010-12-24T09:50:39.994493Z Chris Liddell

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

>     Bug 691850

>     No cluster differences expected.

> [psi/zfapi.c]

2010-12-24T00:28:30.327488Z Alex Cherepanov

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

> [base/configure.ac]

2010-12-23T14:39:36.123969Z Ken Sharp

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

> [base/gsfcmap.c]

2010-12-23T11:41:20.825457Z Ken Sharp

>     ps2write enhancement

>     Initialise the SetPageSize flag to true when ProduceDSC is set, so that page sizes are
>     properly requested by the output PostScript file.

>     No differences expected.

> [base/gdevpdfu.c]

2010-12-22T18:48:13.456231Z Michael Vrhel

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

> [toolbin/color/halftone toolbin/color/halftone/halfttoning.sln toolbin/color/halftone/halfttoning/halfttoning.vcproj toolbin/color/halftone/halfttoning toolbin/color/halftone/halfttoning/halftone.c]

2010-12-22T16:17:58.830786Z Ken Sharp

>     Just remove a commented out line of code that should have been removed before commit.

> [base/gdevpdfb.c]

2010-12-22T14:05:56.481488Z Ken Sharp

>     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

> [base/gdevpdfb.c base/gdevpdti.c]

2010-12-22T13:58:29.830017Z Ken Sharp

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

>     No differences expected.

> [base/gxccache.c]

2010-12-22T00:35:56.638864Z regression

>     Fixed bug with r11967 that redirected output to the wrong directory on the
>     cluster nodes.

> [toolbin/localcluster/run.pl]

2010-12-21T23:07:47.064606Z Marcos H. Woehrmann

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

> [toolbin/localcluster/run.pl]

2010-12-21T23:01:04.915150Z regression

>     Merge run.pl and build.pl with nightly regression versions.

> [toolbin/localcluster/clustermonitor.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]

2010-12-21T17:53:45.618494Z Chris Liddell

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

>     Bug 691810

>     No cluster differences expected.

> [Resource/Init/gs_fntem.ps Resource/Init/gs_fapi.ps]

2010-12-21T10:44:01.003179Z Chris Liddell

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

> [psi/fapiufst.c base/gxfapiu.c]

2010-12-20T16:38:54.977548Z Chris Liddell

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

> [psi/zfapi.c]

2010-12-18T19:27:14.937495Z Alex Cherepanov

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

> [base/sjpx_luratech.c]

2010-12-18T15:24:43.064303Z Ken Sharp

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

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

>     No differences expected

> [base/gsicc_manage.c]

2010-12-17T16:58:35.097740Z Till Kamppeter

>     Install the CJK examples.

> [base/unixinst.mak]

2010-12-17T16:56:51.880152Z Till Kamppeter

>     Mention "ps2pdf14" in the man page for ps2pdf.

> [man/ps2pdf.1 man/de/ps2pdf.1]

2010-12-17T16:54:53.331106Z Till Kamppeter

>     Let Ghostscript work with the libjasper provided by the system.

> [base/sjpx.c]

2010-12-17T16:50:49.932561Z Till Kamppeter

>     pphs is a script and not a library, put it into the correct group of files in the Makefile.

> [base/unixinst.mak]

2010-12-17T16:48:02.245525Z Till Kamppeter

>     Fix stone-old security advisory CVE-2009-4270.

> [base/gsmisc.c]

2010-12-17T16:43:02.736497Z Till Kamppeter

>     Build gsx and gsc executables correctly as executables and not as shared libraries.

> [base/unix-dll.mak]

2010-12-17T00:16:41.356524Z Till Kamppeter

>     Removed patch noise file.

> [contrib/pcl3/eprn/eprnrend.c.orig]

2010-12-16T17:00:24.131587Z Ken Sharp

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

> [base/gdevpdfd.c]

2010-12-15T16:12:54.275384Z Ken Sharp

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

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

2010-12-15T08:22:58.985898Z Ken Sharp

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

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

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

> [base/gdevpdfx.h base/gdevpdf.c Resource/Init/opdfread.ps base/gdevpdfu.c]

2010-12-13T11:57:36.965203Z Ken Sharp

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

> [base/gdevpdfg.h base/gdevpdf.c base/gdevpdfe.c base/gdevpdfu.c]

2010-12-12T16:18:59.870768Z Alex Cherepanov

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

> [base/gsmisc.c]

2010-12-11T23:02:25.039826Z Alex Cherepanov

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

> [base/gximag3x.c]

2010-12-10T19:50:53.800825Z Michael Vrhel

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

> [base/gdevp14.c base/gdevp14.h base/gstrans.c base/gstparam.h base/gxblend.c base/gstrans.h base/gxblend.h]

2010-12-10T13:26:11.089772Z Ken Sharp

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

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

2010-12-10T03:06:40.558274Z Michael Vrhel

>     Apply proper alpha blending to compute luminosity of mask per the PDF specification.  Fixes bug 691822

> [base/gdevp14.c]

2010-12-09T16:50:55.001506Z Ken Sharp

>     undo revision 11941 and 11942 as this causes seg faults on Linux.

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

2010-12-09T15:39:10.142451Z Chris Liddell

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

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

>     Bugs 691778 and 691777

> [psi/fapi_ft.c]

2010-12-09T14:35:26.421173Z Ken Sharp

>     fix pdfwrite

>     Revision 11941 had a typo in gdevpdf.c which spelled %%EndProlog with too many %
>     characters.

> [base/gdevpdf.c]

2010-12-09T14:20:46.589285Z Ken Sharp

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

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

2010-12-07T14:14:20.090005Z Ken Sharp

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

> [base/gdevpdf.c base/gdevpdfu.c]

2010-12-06T20:30:42.463413Z Michael Vrhel

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

> [base/gscdevn.c base/gdevp14.c base/gsicc.c]

2010-12-06T16:39:46.324844Z Alex Cherepanov

>     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

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

> [base/sjpx_luratech.c base/sjpx_luratech.h]

2010-12-06T16:07:30.222320Z regression

>     Limit clusterpush.pl bmpcmp jobs to 10 megs of changes per file in addition to the 100 changes per file limit.

> [toolbin/localcluster/checkSize.pl toolbin/localcluster/clustermonitor.pl toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl]

2010-12-04T21:12:37.349224Z Michael Vrhel

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

> [base/gsicc_create.c Resource/ColorSpace/DefaultRGB]

2010-12-04T12:02:00.835522Z Ken Sharp

>     Remove some extraneous debugging code and variables left in accidentally with the commit
>     for revision 11932.

> [base/gxfcopy.c]

2010-12-04T11:53:13.468703Z Ken Sharp

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

> [base/gxfont1.h base/gxfcopy.c]

2010-12-03T09:20:28.129989Z Ken Sharp

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

> [base/gdevpdti.c]

2010-12-02T18:16:53.794801Z Michael Vrhel

>     Remove unused variable.

> [base/gxblend.c]

2010-12-02T17:09:45.886919Z Michael Vrhel

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

> [base/gdevp14.c base/gdevp14.h base/gxblend.c base/gxblend.h]

2010-12-02T09:58:28.497029Z Ken Sharp

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

> [psi/imain.c]

2010-12-01T16:41:20.443841Z Michael Vrhel

>     Additional debug code to help in soft mask problems.

> [base/gdevp14.c]

2010-12-01T05:16:55.267986Z Michael Vrhel

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

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

> [base/gdevp14.c base/gxclimag.c base/gxcldev.h]

2010-11-29T21:12:32.441057Z regression

>     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

> [toolbin/localcluster/clustermaster.pl toolbin/localcluster/run.pl]

2010-11-29T18:55:03.883221Z Michael Vrhel

>     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

> [base/gsicc_manage.c Resource/Init/gs_lev2.ps]

2010-11-29T18:30:38.060525Z Michael Vrhel

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

> [base/gdevp14.c]

2010-11-29T14:45:17.958276Z Chris Liddell

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

> [Resource/Init/pdf_draw.ps]

2010-11-29T14:35:25.792013Z Ken Sharp

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

> [base/gdevpdtt.c]

2010-11-27T18:23:43.131547Z Ken Sharp

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

> [base/gdevpdfx.h]

2010-11-26T10:59:51.673656Z Chris Liddell

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

> [psi/fapiufst.c]

2010-11-25T21:03:22.187304Z Robin Watts

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

> [base/gxclipm.c]

2010-11-25T09:12:13.562173Z Ken Sharp

>     Remove a now-unused variable to silence a compiler warning.

>     No differences expected.

> [base/gdevpdfb.c]

2010-11-24T22:18:34.999818Z Michael Vrhel

>     Style clean up of gdevp14.c for white space, comments, long lines and dead code.

> [base/gdevp14.c]

2010-11-24T17:44:39.808162Z Michael Vrhel

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

> [Resource/Init/pdf_ops.ps base/gdevp14.c base/gxclimag.c base/gxblend.c base/gstrans.h base/gxblend.h]

2010-11-24T16:21:25.266704Z Ken Sharp

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

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

> [base/gdevpdfb.c base/gdevpdti.c]

2010-11-23T16:01:44.675647Z Ray Johnston

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

> [base/gsmchunk.c]

2010-11-23T15:36:28.976110Z Robin Watts

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

>     The fix is to move the code that finds the underlying allocator to before
>     we free the memory.

>     Cluster testing shows no differences.

> [base/gxclthrd.c]

2010-11-23T12:33:56.433376Z Robin Watts

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

>     Comment change only - no cluster changes expected.

> [base/gxshade1.c]

2010-11-23T08:46:10.878077Z Ken Sharp

>     Revert revision 11901.

>     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 code will be revised and recommitted.

> [base/gdevpdti.h base/gdevpdfx.h base/gdevpdfb.c base/gdevpdt.h base/gdevpdti.c base/gdevpdfi.c]

2010-11-20T22:55:09.754787Z regression

>     Improved the cluster code's ability to be able to recover from machines going down late in the run.

> [toolbin/localcluster/clustermaster.pl toolbin/localcluster/run.pl]

2010-11-18T19:21:31.928351Z Chris Liddell

>     Ensure we set SHARE_FT correctly when we end up using the system installed
>     freetype library.

>     Bug 691776.

>     No cluster differences expected.

> [base/configure.ac]

2010-11-18T00:52:20.670104Z regression

>     Two changes to the local cluster system:

>     1.  A warnings check is now performed on the code under test (both commit
>     and user tests).

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

>     Also some minor cleanup (dividing the clustermaster log into .log and
>     .dbg files, supressing some uneeded debugging messages, etc.)

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

2010-11-16T22:49:26.969992Z Ray Johnston

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

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

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

2010-11-16T14:48:31.620067Z Michael Vrhel

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

> [base/gsicc_manage.c psi/zusparam.c base/gsicc_manage.h lcms/src/cmsgmt.c]

2010-11-16T14:33:57.040738Z Ken Sharp

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

> [base/gdevpdti.h base/gdevpdfx.h base/gdevpdfb.c base/gdevpdt.h base/gdevpdti.c base/gdevpdfi.c]

2010-11-16T13:58:36.196330Z Alex Cherepanov

>     Prefer character codes < 256 during construction of /CharStrings and
>     /Encoding attributes of a symbolic Type 42 font. Bug 691753.

> [Resource/Init/gs_ttf.ps]

2010-11-15T18:30:50.012584Z Henry Stiles

>     reverts 11877 which needs a bit more work

> [base/gsmchunk.c]

2010-11-15T09:11:50.168011Z Chris Liddell

>     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

>     (NOTE: the test file for this still appears to go into an infinite loop
>     during interpolation).

> [base/gxiscale.c]

2010-11-14T21:16:15.954493Z Michael Vrhel

>     Make a macro for the default ICC profile name and set it in the proper locations.

> [base/gsicc_manage.c psi/zusparam.c base/gsicc_manage.h]

2010-11-06T15:36:18.568592Z Michael Vrhel

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

> [base/lib.mak base/gsdparam.c base/gsicc_manage.c]

2010-11-05T22:12:05.617541Z Michael Vrhel

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

> [base/gxblend1.c]

2010-11-05T15:53:35.817121Z Chris Liddell

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

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

>     Bug 691750.

> [psi/zfapi.c]

2010-11-04T19:13:08.201769Z Michael Vrhel

>     Increase in curve size to enable sharper cut offs (i.e. no interpolation of curve points) for thresholding profiles.

> [toolbin/color/icc_creator/ICC_Creator/icc_create.cpp]

2010-11-03T20:44:07.993086Z Michael Vrhel

>     Fix to avoid potential crash instead of error if an improper file name is given for the device ICC profile.

> [base/gsicc_manage.c]

2010-11-02T17:16:24.985382Z Chris Liddell

>     Remove some unnecessary, and detrimental endian related code
>     in the GS/lcms interface.

>     Bug 691696

>     No cluster differences expected.

> [base/gsicc_cache.c base/gsicc_littlecms.c]

2010-11-01T23:59:27.933765Z Michael Vrhel

>     Performance fix so that the md5 code is not used to hash the rendering conditions for the icc link.

> [base/gsicc_cache.c base/gscms.h]

2010-10-31T03:26:19.022477Z Ray Johnston

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

> [base/gsmchunk.c]

2010-10-30T03:40:36.798714Z Alex Cherepanov

>     Check for negative object nunbers and consider such objects as null.
>     Bug 691740, customer 384.

> [Resource/Init/pdf_base.ps]

2010-10-29T23:40:30.279741Z Michael Vrhel

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

> [base/gxipixel.c base/gxidata.c base/gximage.h]

2010-10-29T19:35:48.071618Z Henry Stiles

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

> [base/gxipixel.c]

2010-10-29T16:37:41.020300Z Michael Vrhel

>     Added features and fixed bugs to enable creation of thresholding ICC profiles.

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

2010-10-29T09:05:42.895454Z Ken Sharp

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

> [base/gscdevn.c psi/zcolor.c]

2010-10-28T20:41:14.761110Z Michael Vrhel

>     Addition in profile creation tool to create Gray ICC profiles with abrupt thresholds.   Needed for solution to bug 691737

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

2010-10-28T19:57:51.569853Z Michael Vrhel

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

> [base/gsicc_create.c base/gsicc_manage.c base/gscms.h base/gsciemap.c]

2010-10-28T19:02:45.723574Z Robin Watts

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

> [base/gdevtifs.c]

2010-10-28T15:00:37.200667Z Chris Liddell

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

> [/trunk/ghostpdl/Makefile base/Makefile.in]

2010-10-28T06:12:53.429268Z Michael Vrhel

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

> [base/gxclpath.c base/gxclimag.c base/gxclist.h base/gxclrast.c]

2010-10-28T04:12:55.507828Z Marcos H. Woehrmann

>     Added dependencies to devs.mak to allow minftrsz.c to compile with concurrent make.

> [base/devs.mak]

2010-10-27T23:30:42.045125Z Robin Watts

>     Fix compiler warning.

>     No expected differences.

> [base/gdevtifs.c]

2010-10-27T19:48:01.087645Z Robin Watts

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

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

2010-10-27T12:45:49.361211Z Robin Watts

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

> [doc/Devices.htm base/gdevtfax.c]

2010-10-27T11:18:38.076346Z Robin Watts

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

> [base/gdevtifs.c]

2010-10-26T23:54:13.691521Z Robin Watts

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

> [base/gxclimag.c]

2010-10-26T20:30:32.970049Z Michael Vrhel

>     Fix for RGB byte order expected by new CMM compared to imdi libray.

> [base/gdevwts.c]

2010-10-26T20:22:45.373077Z Robin Watts

>     Silence gcc warning.

> [base/gdevfax.c]

2010-10-26T19:41:35.752819Z Michael Vrhel

>     Removal of accidental commit of my own path for the wts halftone planes.

> [base/gdevwts.c]

2010-10-26T18:50:49.267717Z Michael Vrhel

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

> [base/gdevwts.c]

2010-10-26T18:10:15.277289Z Robin Watts

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

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

2010-10-26T14:14:24.874268Z Alex Cherepanov

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

> [base/sjpx_luratech.c]

2010-10-25T16:51:26.885213Z Alex Cherepanov

>     Change the interface to Luratech JPX library to extract image data or
>     opacity depending on the alpha parameter.

> [base/sjpx_luratech.c]

2010-10-25T15:59:10.973330Z Ken Sharp

>     Fix pdfwrite : Do not emit DeviceRGB/CMYK as an Alternate when disallowed by PDF/A or X

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

>     As a result invalid PDF/A or PDF/X files could be written.

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

>     The new base space is then written to the PDF file.

>     No differences expected as we don't test PDF/A and PDF/X on the cluster.

> [base/gdevpdfc.c]

2010-10-25T06:23:22.846885Z Alex Cherepanov

>     Move initialization of state->alpha flag to the place where it has effect.

> [base/sjpx_luratech.c]

2010-10-25T04:39:51.229054Z Alex Cherepanov

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

> [base/sjpx_luratech.c base/sjpx_luratech.h psi/msvc32.mak]

2010-10-25T04:16:46.177854Z Alex Cherepanov

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

> [base/gxpcmap.c]

2010-10-24T22:23:55.448411Z Alex Cherepanov

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

> [base/sjpx.c Resource/Init/pdf_draw.ps]

2010-10-23T22:38:17.069244Z Alex Cherepanov

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

> [Resource/Init/pdf_draw.ps]

2010-10-22T09:29:10.157074Z Chris Liddell

>     Add a debug-clean target (which in turn calls the existing debugclean target)
>     to be more consistent with the ghostpdl langauge builds.

>     No cluster differences expected.

> [base/Makefile.in]

2010-10-22T07:52:12.054756Z Ken Sharp

>     Remove a spurious space that was causing a compiler warning, and remove an unused
>     function, also causing a compiler warning.

> [base/gdevpdfu.c]

2010-10-22T06:38:49.083740Z Alex Cherepanov

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

> [Resource/Init/pdf_base.ps]

2010-10-22T04:19:30.192593Z Alex Cherepanov

>     Recognize /SMaskInData attribute as an indicator that the page has
>     transparency features. Establish a base level for a future regression
>     testing.

> [Resource/Init/pdf_main.ps]

2010-10-21T15:57:37.250433Z Ken Sharp

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

>     Don't emit %PDF header when producing DSC PostScript.

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

> [base/gdevpdf.c base/gdevpdfu.c]

2010-10-21T14:09:27.225155Z Marcos H. Woehrmann

>     Updated the cluster new node instructions to test the cups device
>     when verifying the installation is complete.

> [toolbin/localcluster/readme]

2010-10-21T13:39:00.821724Z Marcos H. Woehrmann

>     Added the cups dev repositories to the cluster node sertup read.me

> [toolbin/localcluster/readme]

2010-10-21T11:17:31.420556Z Ken Sharp

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

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

>     No differences expected.

> [base/gdevpdf.c]

2010-10-21T11:07:40.293085Z Ken Sharp

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

> [base/gdevpdfu.c]

2010-10-21T08:22:47.321512Z Ken Sharp

>     Remove some unused variables to silence compiler warnings.

> [base/gdevpdfu.c]

2010-10-21T02:48:48.797956Z Alex Cherepanov

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

> [Resource/Init/gs_res.ps]

2010-10-20T17:00:27.929678Z Robin Watts

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

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

> [base/valgrind.h base/gsmdebug.h]

2010-10-20T16:59:51.575415Z Alex Cherepanov

>     Add /ZapfDingbats to the list of known symbolic fonts, which ignore bogus
>     /Encoding attribute. Fix fts_23_2300.pdf rendering.

> [Resource/Init/pdf_font.ps]

2010-10-20T16:05:28.326890Z Ken Sharp

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

> [base/gdevpdfu.c]

2010-10-20T14:45:48.119859Z Ken Sharp

>     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 differences expected.

> [base/gdevpdfx.h base/gdevpdfp.c base/gdevpdfb.h]

2010-10-20T10:59:23.603495Z Robin Watts

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

> [base/gxclimag.c]

2010-10-20T10:21:50.512085Z Robin Watts

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

>     No changes expected in testing (and clusterpush agrees).

> [base/gxclimag.c]

2010-10-19T08:04:32.778817Z Ken Sharp

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

> [base/gxtype1.c]

2010-10-18T15:44:20.143696Z Chris Liddell

>     Silence a compiler warning from my previous commit.

> [psi/zchar42.c]

2010-10-18T14:11:44.566085Z Chris Liddell

>     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

>     No cluster differences expected.

> [psi/zchar42.c]

2010-10-16T15:52:53.774342Z Ken Sharp

>     Fix pdfwrite: Don't use CFF font format if CompatibilityLevel < 1.2

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

> [base/gdevpdfp.c]

2010-10-15T15:12:36.033471Z Ken Sharp

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

> [base/gdevpdtt.c base/gdevpdti.c]

2010-10-15T15:07:05.687999Z Chris Liddell

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

>     No cluster differences expected.

> [psi/fapi_ft.c]

2010-10-15T14:21:51.952651Z Ken Sharp

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

> [base/gdevpdfd.c]

2010-10-14T20:23:15.984226Z Henry Stiles

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

> [base/gximono.c]

2010-10-14T15:06:01.276381Z Chris Liddell

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

>     patch credit to William Bader.

>     Bug 691651.

>     No cluster differences expected.

> [base/gxccman.c]

2010-10-14T15:01:56.645831Z Chris Liddell

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

>     No cluster differences expected.

> [psi/zfapi.c]

2010-10-14T14:57:36.364971Z Chris Liddell

>     Rename libpng.mak to png.mak to make it consistent with the other
>     third part libraries.

>     Bug 691681

>     No cluster differences expected.

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

2010-10-14T14:23:22.009615Z Till Kamppeter

>     CUPS Raster output device: Fixed access to uninitialized variable, the margins array is only set when size_set is true (bug #691683).

> [cups/gdevcups.c]

2010-10-14T11:57:31.187468Z Chris Liddell

>     Rename libtiff.mak to tiff.mak to be more consistent with the other third party libs.

>     Bug 691681

>     No cluster differences expected.

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

2010-10-13T17:14:59.959208Z Robin Watts

>     Fix 2 build warnings in gdevtifs.c

>     No expected differences.

> [base/gdevtifs.c]

2010-10-13T16:01:51.166726Z Robin Watts

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

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

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

2010-10-13T10:48:04.352147Z Chris Liddell

>     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

>     No cluster differences expected.

> [Resource/Init/gs_fntem.ps]

2010-10-12T23:27:36.478231Z Robin Watts

>     Remove unused variable in siscale.c that was causing warnings.

>     No expected differences.

> [base/siscale.c]

2010-10-12T16:26:32.204667Z Robin Watts

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

>     Testing with my custom dropout test file shows a huge improvement with the
>     new code. I'll add this to the test repo shortly.

> [base/siscale.c]

2010-10-12T05:52:16.851470Z Michael Vrhel

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

> [psi/zpcolor.c base/gxpcmap.c]

2010-10-11T07:53:26.581165Z Chris Liddell

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

>     No cluster differences expected.

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

2010-10-10T05:51:09.780940Z regression

>     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

> [toolbin/localcluster/clustermonitor.pl toolbin/localcluster/clustermaster.pl toolbin/localcluster/build.pl toolbin/localcluster/run.pl toolbin/localcluster/compare.pl]

2010-10-08T14:42:18.915016Z Ken Sharp

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

> [base/gdevpdte.c]

2010-10-08T13:42:41.451688Z Ken Sharp

>     Remove an unused variable (flagged by static analysis).

> [base/gdevpsdi.c]

2010-10-08T13:37:05.002251Z Ken Sharp

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

> [base/gdevpdtt.c]

2010-10-08T13:34:00.715868Z Ken Sharp

>     Remove an unused variable (flagged by static analysis)

> [base/gdevpdfi.c]

2010-10-08T13:31:11.163393Z Chris Liddell

>     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

>     No cluster differences expected.

> [psi/fapi_ft.c]

2010-10-08T12:01:24.908534Z Ken Sharp

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

> [base/gdevpdtt.c]

2010-10-08T05:09:27.837431Z Ray Johnston

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

> [base/gdevp14.c]

2010-10-07T13:59:49.890609Z Ken Sharp

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

> [base/gdevpdfj.c base/gdevpdfp.c base/gdevpdfu.c]

2010-10-07T12:49:54.318945Z Ken Sharp

>     More changes to silence static analysis warnings. Mostly removing unused variables or
>     assignments.

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

2010-10-07T08:35:58.544234Z Ken Sharp

>     Silence (hopefully) some compiler warnings.

> [base/gdevpdf.c]

2010-10-07T08:04:15.270260Z Ken Sharp

>     Remove some unused variables and assignments flagged by static analysis.

> [base/gdevpdfg.c]

2010-10-07T07:57:43.664608Z Ken Sharp

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

> [base/gdevpdfd.c]

2010-10-07T07:50:09.274081Z Ken Sharp

>     Static analysis discovered two variables being altered that are not subsequently used.
>     Although this is safe, removed the code anyway.

> [base/gdevpdfb.c]

2010-10-07T07:49:13.279339Z Ken Sharp

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

> [base/gdevpdf.c]

2010-10-06T14:03:32.653153Z Robin Watts

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

> [base/gxclist.c]

2010-10-06T13:48:15.425458Z Ken Sharp

>     Add some body parentheses to 'if' statements in order to silence some clang warnings.

> [base/gdevpdfp.c base/gdevpdtf.c]

2010-10-06T12:06:46.017717Z Robin Watts

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

> [base/gxiscale.c]

2010-10-05T21:38:11.272406Z Robin Watts

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

> [psi/zfapi.c]

2010-10-05T20:27:54.714250Z Michael Vrhel

>     Clean up of a few comments about device profiles

> [base/gsicc_manage.c]

2010-10-05T20:18:10.046358Z Michael Vrhel

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

> [base/gsicc_manage.c]

2010-10-05T13:57:22.688207Z Alex Cherepanov

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

> [Resource/Init/pdf_sec.ps]

2010-10-05T12:48:16.473671Z Ken Sharp

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

> [base/gdevpsdi.c base/gdevpdfi.c]

2010-10-05T12:10:46.672154Z Robin Watts

>     Fix for part 1 of Bug 691635, supplied by Norbert Janssen. Many thanks.

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

>     No expected changes.

> [base/gsiodisk.c]

2010-10-03T16:13:00.326561Z Alex Cherepanov

>     Change the order of operands in a logical expression to avoid dereferencing
>     an uninitialized variable. Bug 690214.

> [psi/zfont2.c]

2010-10-01T19:36:06.952768Z Ray Johnston

>     Drop support for these less popular compilers. This will be the first step to
>     changing to project files for Windows.

> [base/wctail.mak base/watclib.mak base/bcwin32.mak base/gp_iwatc.c base/watcw32.mak base/wccommon.mak]

2010-10-01T02:58:15.408387Z Alex Cherepanov

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

> [doc/Use.htm psi/int.mak psi/zfont1.c psi/zfont2.c Resource/Init/gs_cff.ps]

2010-09-29T15:50:22.840688Z Ray Johnston

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

> [base/gdevp14.c]

2010-09-28T12:36:41.051799Z Ken Sharp

>     Fix (pdfwrite) : Don't unreasonably limit the PDF output level

>     Bug #691318 " -dCompatibilityLevel=1.6 produces PDF 1.5"

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

> [base/gdevpdfp.c]

2010-09-28T12:26:13.182021Z Ken Sharp

>     Fix (pdfwrite) : allow for UserPasword and OwnerPassword in page device

>     Bug #691256 "OwnerPassword and UserPassword don't work as device parameters"

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

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

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

>     No expected differences.

> [base/gdevpdfp.c]

2010-09-27T12:05:17.449032Z Ken Sharp

>     Fix (Fonts): Prevent xfont being used in composefont

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

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

>     No differences expected.

> [base/gxchar.c]

2010-09-27T09:33:55.410495Z Ken Sharp

>     Fix (pdfwrite/ps2write) : Don't dereference mask colour spaces

>     Bug #691106 "-sDEVICE=pdfwrite -dConvertCMYKImagesToRGB=true"

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

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

> [base/gdevpsdi.c]

2010-09-25T02:08:22.451780Z Alex Cherepanov

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

> [lib/ps2pdf.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat]

2010-09-24T13:25:07.243032Z Chris Liddell

>     For disk based TTFs, only lookup the character code in the TTF cmap if the font is
>     not using an Identity ordering.

>     No cluster differences expected.

>     Bug 691623.

> [psi/zfapi.c]

2010-09-24T09:03:34.206583Z Ken Sharp

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

>     At the same time, removed the functions:
>     add_quadratic_curve
>     append_simple
>     check_component

>     These were only called by each other, or by append_component which had already been
>     removed as unused.

>     No expected differences.

> [base/gstype42.c]

2010-09-24T03:27:45.689228Z Michael Vrhel

>     Removal of debug code that was accidentally committed.

> [base/gdevp14.c]

2010-09-23T19:45:27.249371Z Michael Vrhel

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

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

2010-09-23T14:46:50.766627Z Robin Watts

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

> [base/gdevp14.c]

2010-09-23T12:17:57.296649Z Robin Watts

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

> [base/gxclrast.c]

2010-09-23T10:46:33.821569Z Robin Watts

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

> [base/gsropt.h]

2010-09-23T08:16:36.207911Z Ken Sharp

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

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

> [base/gdevpdtt.c]

2010-09-22T15:13:20.906048Z Marcos H. Woehrmann

>     Removed unused label from base/gxicolor.c that caused compiler warning.

>     Fixes Bug #691633 reported by Norbert Janssen.

> [base/gxicolor.c]

2010-09-21T12:03:52.655546Z Chris Liddell

>     Add the new entries for produce outlines and maximum bitmap size
>     to the FAPI server declarations in the UFST and Bitstream code.

>     No cluster differences expected.

>     Bug 691634

> [psi/fapiufst.c psi/fapibstm.c]

2010-09-20T01:26:14.070109Z Alex Cherepanov

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

> [psi/zfrsd.c]

2010-09-17T10:29:36.728794Z Robin Watts

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

> [base/gsbitops.h]

2010-09-17T06:44:27.206613Z Michael Vrhel

>     Removal of unused variable introduced in last commit.

> [base/gdevp14.c]

2010-09-17T05:40:48.428712Z Michael Vrhel

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

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

2010-09-16T14:57:06.777148Z Alex Cherepanov

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

> [lib/ps2pdf.bat lib/ps2pdf12.bat lib/ps2pdf13.bat lib/ps2pdf14.bat]

2010-09-16T11:09:31.082242Z Robin Watts

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

> [base/gxclrast.c]

2010-09-16T11:05:47.689000Z Robin Watts

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

>     This still leaves bug 690993 open.

>     No expected differences.

> [base/gsbitops.c base/gsbitops.h base/gxclbits.c]

2010-09-15T08:15:52.075230Z Ken Sharp

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

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

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

>     No differences expected, the regression suite doesn't test ps2write.

> [Resource/Init/opdfread.ps]

2010-09-14T12:58:09.089527Z Ken Sharp

>     Fix (pdfwrite) : Don't colour convert SMask images

>     Bug #690612 "PDF sRGB conversion loses images"

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

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

>     No expected differences.

> [base/gdevpdfi.c]

2010-09-14T09:07:06.998296Z Ken Sharp

>     Fix a compiler warning.

> [base/gdevpdfo.c]

2010-09-14T08:06:03.949247Z Ken Sharp

>     pdfwrite enhancement : performance improvement with type 3 fonts

>     Bug #690575 "PS to PDF Conversion extremely slow (possibly endless)"

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

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

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

> [base/gdevpdfo.c base/gdevpdfo.h]

2010-09-14T07:49:11.816447Z Chris Liddell

>     Bump version number to 9.01 and associated changes.

> [base/gscdef.c base/version.mak Resource/Init/gs_init.ps]